Performance issues

[mockdeep]

Right now we're running with the command line options '-t reactify --extension=".js.jsx"' and it takes a couple of minutes to compile assets, which is already pretty slow. I'm trying to switch to babelify with a couple of presets, '-t babelify --extension=".js.jsx"', but it slows to a point where it times out our CI build. It eventually compiles if I run it locally, but still takes a few minutes. Sprockets itself tends to be pretty fast, and it seems like browserify is generally pretty performant, so does that mean something in how they interface is the problem?

[bufordtaylor]

I'm experiencing the same problem.

[avk]

@mockdeep just an FYI that could be totally unrelated but I solved a recent performance issue with browserify in production. Seems like live compilation, enabled by this line:

config.assets.compile = true

was causing browserify to recompile even after successful rake assets:precompiles on production deploys.

I found this by comparing my asset pipeline config to the stock one generated by the latest sprockets-rails. Maybe that could help with your CI build. Good luck!

[mockdeep]

@avk unfortunately, that's not the issue for us. Production is fine, it's just when deploying, any time we make changes in development, and running our CI build.

[cymen]

Do you have browserify-incremental enabled? I think the fundamental issue is around how many times you enter from non-browserify to browserified code. In other words, if I have just one big JavaScript bundle with one file that does a require (gets detected as CommonJS) and then browserify handles the code "under that" (as in, it uses CommonJS all the way down), performance should be okay.

It might be that the newer sprockets expects better caching (via sprockets itself) than we are currently doing. So that would be another thing to explorer -- basically, it looks like sprockets can do caching now and we might not be interfacing with that well.

The easiest way to see what is going on is probably to put some logging into the gem (git clone it, modify it locally and then require it relatively in Gemfile). That is a pain but it's a good way to dig into what might be happening.

Unfortunately, I do expect there are limitations fundamentally to how performant browserify-rails can be. That is one reason I really advocate for using it to get to CommonJS and then jumping off to other solutions that will have better performance.

[mockdeep]

Yeah, we've got browserify-incremental enabled. We still do have a lot of sprockets requires, though, so I figure once we get those sorted out it will hopefully improve. Still, it would be nice if the transition weren't so painful. May dig into it on a future hack day at our office.

[cymen]

@mockdeep That would be great. I used to use browserify-rails on a fairly large project but I don't have a good use case anymore and am not using it regularly. Trying to create examples with complex usage is a bit troublesome. But if you have time to dig in, that would be awesome.

[dspoonia7]

In local machine, Browserify is making lots of cache queries. Which is causing minutes to load the page and sometimes even system hangs up. How can I optimise on this?

Here are my application.rb and package.json files.

Related issue.

[cymen]

@dspoonia7

What versions of browserify and browserify-incremental are you using? Have you tried some older versions?

Are you entering from asset pipeline JavaScript to browserified JavaScript via a single path? Like basically you have one bundle like application.js and in that one, you pull in some JavaScript which is going to be browserified (and none of that code uses asset pipeline // require or anything like that)...

If this is a new project, I highly recommend using webpack outside of the asset pipeline.

[dspoonia7]

Hey @cymen
Currently I am using "browserify": "^13.1.0", "browserify-incremental": "^3.1.1" as mentioned in my package.json.
But I also have tried "browserify": "^10.2.6", "browserify-incremental": "^3.1.1", got same result.

I have some plugin files in vendor folder, which uses rails assets pipeline. Here is my application.js

Actually its not a new project but we are planning to move to react. Currently our app is on angular.
I am also planning to use webpack. It would be great if you can link me to a working example like this one github.com/gauravtiwari/browserify-rails

[cymen]

@dspoonia7 Ah! Sorry, I missed the package.json (not sure how). I do think rails-browserify works great for moving to CommonJS (and then, if desired, stepping off the asset pipeline).

There is a sample on this org too here https://github.com/browserify-rails/multiple-bundles-example however it is somewhat out of date. We should update it.

I'll try to think what might be causing your issue.

[avk]

Just a note that multiple JS manifests in the asset pipeline seem to considerably slow down browserify-rails, regardless of whether they each have one CommonJS require() or several.

[mcmire]

I am noticing that if I modify a file that has many dependents, Sprockets ends up running several browserify calls in serial, each of which takes around 2-3 seconds. If Sprockets were able to execute commands to compile assets in parallel that would greatly speed things up. Alternatively, if Sprockets only ran one command (I'm not sure why it runs several commands, to be honest) then it seems that Browserify should be able to compile files in parallel.

[mockdeep]

Still having pretty bad performance issues even after we've converted all of our code to use node-style requires. One thing I see is that there are a lot of "Browserify: " output lines still showing up in the logs, even though we've only got a handful of links in our sprockets manifest file. I'm wondering if it's somehow piping extra files through, but haven't been able to get much useful information going through the source code of either sprockets or browserify-rails. Not too sure what to try next. Will probably toy around with running a profiler.

[cymen]

@mockdeep Are you able to move some or all of the JS build to a separate process running webpack or browserify directly? If so, I'd highly recommend it. But PRs are definitely welcomed to improve the performance of browserify-rails too.

My gut feeling regarding performance is that this project will work well up to a certain point but it will often feel sluggish. So it works well to migrate to say CommonJS and then potentially revisit the build approach and consider using another tool directly (browserify, webpack, rollup, etc).

But there is more than one way to do it of course. I am not (strongly) advocating any path.

[mockdeep]

I think I might give webpack-rails a try, but I'd prefer a solution that integrates smoothly with the asset pipeline, at least insofar as Rails supports it. Sprockets has always been fairly performant, so it's a little strange to me that this pairing doesn't work out that well.

[omederos]

Something similar is happening to us. No issues in development, but running rake assets:precompile when deploying in production takes a few minutes before it prints the first precompiled assets on the console.

Is it possible to enable something (env variable, parameter, etc) to see what's taking so long?