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

Bad compile time performance #24

Closed
qyoz opened this Issue Sep 21, 2016 · 11 comments

Comments

Projects
None yet
7 participants
@qyoz

qyoz commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MatrixFrog

MatrixFrog Sep 21, 2016

Contributor

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.

Contributor

MatrixFrog commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@qyoz

qyoz Sep 21, 2016

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?

qyoz commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@MatrixFrog

MatrixFrog Sep 21, 2016

Contributor

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.

Contributor

MatrixFrog commented Sep 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Dominator008

Dominator008 Sep 21, 2016

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

Dominator008 commented Sep 21, 2016

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

@qyoz

This comment has been minimized.

Show comment
Hide comment
@qyoz

qyoz Sep 22, 2016

@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.

qyoz commented Sep 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Akkuma

Akkuma Jul 18, 2017

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

Akkuma commented Jul 18, 2017

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 nazar-pc referenced this issue Aug 13, 2017

Open

[WIP] Google closure compiler js #5464

1 of 3 tasks complete
@nazar-pc

This comment has been minimized.

Show comment
Hide comment
@nazar-pc

nazar-pc Aug 13, 2017

Contributor

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.

Contributor

nazar-pc commented Aug 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@fdietze

fdietze Jun 7, 2018

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.

fdietze commented Jun 7, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ChadKillingsworth

ChadKillingsworth Jun 7, 2018

Collaborator

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

Collaborator

ChadKillingsworth commented Jun 7, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nazar-pc

nazar-pc Jun 7, 2018

Contributor

@ChadKillingsworth, Java version doesn't have this issue

Contributor

nazar-pc commented Jun 7, 2018

@ChadKillingsworth, Java version doesn't have this issue

@ChadKillingsworth

This comment has been minimized.

Show comment
Hide comment
@ChadKillingsworth

ChadKillingsworth Jun 8, 2018

Collaborator

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.

Collaborator

ChadKillingsworth commented Jun 8, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment