New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gem is abnormally slow at compiling source-maps #12
Comments
@TylerHorth maybe you can find if this a problem with this gem or with ExecJS (or an specific ExecJS runtime) have you tried to run CoffeeScript compiler directly using ExecJS? On the ExecJS README we have an example about how this can be done. |
Alrighty, I've run some tests and it seems to be a problem with the MiniRacer runtime. ExecJS was defaulting to this runtime in my project. Changing to the Node runtime completely resolves the issue. It's probably safe to close this issue unless you think this Gem should be opinionated as to the runtime that's used. |
Thanks for tracking it!! @SamSaffron you might be interested in this. |
this worries me @TylerHorth do you have a repro somewhere so I can get to the bottom of it? |
I don't have a repo, but it's fairly straight forward to reproduce. I started off by creating a moderately sized CoffeeScript file
|
Tyler, I know it has taken me a while to work through this, but I spent all day today sorting this out. What was happeneing was the mini_racer used to walk v8 object graphs recursively on the boundary between v8 and ruby, something that involved creating lots of contexts and waste. In your case the source maps piece actually generates an object in ruby with 10 of thousands of nodes, this was very expensive to walk. I redid this per With this in place MiniRacer is outperforming node (which is expected) cause our boundary is far more efficient (no need to write files and so on) Thanks so much for the test case here, can you try MiniRacer again? |
#15 should mean a sufficiently recent (read: from git) pair of sprockets + coffee-script doesn't bother sending the complex data across the boundary at all. |
I tested with a single CoffeeScript file of ~20,000 lines to try to rule out environment spin up times. The generated source map for this file is ~20% smaller than the generated Javascript. This seems to be a problem to do with the ExecJS interface, but I don't know where to start seeing as it is only affecting compile time with source maps enabled.
cc @rafaelfranca
The text was updated successfully, but these errors were encountered: