Bad compile time performance

[qyoz]

I benchmarked this port against other transpilers using jQuery and found that it takes an extraordinary ~13 seconds to transpile using closure-compiler-js as opposed to a little over ~1 second with uglifyjs or esprima.

I understand that this port was generated using a Java to JS compiler and looking at jscomp.js it is really not a big surprise as to why this takes so long, there is a lot of redundancy behind the scenes.
However, it pretty much renders this port useless when tranpiling large projects or when using this module in the browser.
If it takes less time to spawn a child process and compile with the native Java compiler then what's the point?
It makes more sense to me to write this module properly from a technical spec than to have something generated and under perform.

[MatrixFrog]

What options are you using? Closure is a lot more than just a transpiler so if you only want to use it for transpilation then you can turn off lots of other things (like typechecking).

That said, we are looking at ways to improve performance, and we are aware that the JS version is likely to be slower right now for some use cases.

[qyoz]

My main use case is minifying a 2.5 MB ES5 project, which with uglifyjs takes ~6 seconds to minify and ~150 seconds with CC.
For uglifyjs, I use the default options + mangle, and for CC I used the example given in the README.
I was originally looking to benchmark compression rates, but either way a two and a half minute compile time is not something I can use in a continuous deployment application life cycle.

What options would you recommend I disable (or enable) for best results for this use case?

[MatrixFrog]

Try both simple mode and advanced mode, and measure the runtime, total code size, and total codesize after gzipping (assuming that you can serve your code gzipped). It may be that the gzipped results are almost the same for simple mode and advanced mode, in which case you probably want to stick to simple mode, which will hopefully be quite a bit faster. Another thing you can try is --tracer_mode=TIMING_ONLY (I don't remember if that flag is available in the JS version, but we can add it if not) which will tell you if a particular pass is being ridiculously slow for some reason. That would be good information for us, to know where to focus on performance improvement.

[Dominator008]

@qyoz Assuming you are using SIMPLE_OPTIMIZATIONS, ~150 seconds vs ~6 seconds definitely sounds bad. Is your project open source by any chance?

[qyoz]

@Dominator008 The project I'm working on is private, that's why I used jQuery as a test case for this benchmark. The difference in compile-time ratio is easily reproduced.

I can tell you that using CC to compile jQuery with the default options (compilationLeve: SIMPLE) takes me ~12 seconds. Compiling with compilationLeve: ADVANCED takes ~21.
This is on a Windows machine, i7-4710MQ @ 2.50GHz, node version 4.2.3 64bit.

@MatrixFrog I've tried both SIMPLE and ADVANCED options for my project and both take over~150 seconds to complete. I do serve these files gzipped but it's not the issue here really.
I'll be happy to test with tracer_mode flag on but I believe it doesn't work programmatically from the JS port. If you do decide to add it I'll be happy to test further.

[Akkuma]

I'm seeing the same problem. GCC is literally unusable and I can't even see what the output is since I am not willing to wait. I have some very large files due to a lot of dependencies with large sizes and uglifyjs can handle this in roughly 30s-60s. GCC 17 minutes later has yet to even complete.

        options: {
          languageIn: 'ECMASCRIPT6',
          languageOut: 'ECMASCRIPT5',
          compilationLevel: 'SIMPLE',
          warningLevel: 'VERBOSE',
        }

Edit: It took a total of 1370.3 s to complete, including general webpack overhead so shave about 20-30s off

[nazar-pc]

Here is reproducible example I'm having troubles with: https://github.com/nazar-pc/closure-compiler-bug-24
It takes about 11 minutes. I'm not even saying about up to 1G memory consumption, which is not a big deal for me, but still quite a lot.

[fdietze]

I can confirm the bad performance even with compilationLevel: 'WHITESPACE_ONLY'. My input file is ~2M with a 7M source map. It took 1773s in total.

[ChadKillingsworth]

I'm closing this issue. The compile time performance isn't directly related to the JS publication to NPM. Any compilation time issues need reported to the main repository: https://github.com/google/closure-compiler

[nazar-pc]

@ChadKillingsworth, Java version doesn't have this issue

[ChadKillingsworth]

This repo doesn't house the source code for the compiler - just the npm distribution and publication. Even the JS version compilation time would need to be addressed in the other repo.