Skip to content
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

Memory Limit on Unexpected JavaScript? #38

Closed
jaswrks opened this issue Aug 29, 2014 · 5 comments
Closed

Memory Limit on Unexpected JavaScript? #38

jaswrks opened this issue Aug 29, 2014 · 5 comments
Assignees
Labels

Comments

@jaswrks
Copy link

@jaswrks jaswrks commented Aug 29, 2014

A user reports the following in their PHP error log...

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 3671889 bytes) in /.../quick-cache-pro/submodules/htmlc/html-compressor/includes/core.php on line 751

This leads back to the JavaScript minification library that comes with the HTML Compressor.

@jaswrks jaswrks self-assigned this Sep 1, 2014
@jaswrks
Copy link
Author

@jaswrks jaswrks commented Sep 3, 2014

Related issue. See: wpsharks/comet-cache#305 (comment)
~ The JS compressor needs to do a better job of handling unexpected code fragments.

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Sep 24, 2014

Another user reports...

PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
quick-cache-pro/submodules/htmlc/html-compressor/includes/core.php
Line: 1620 if(($compressed_js = js_minifier::compress($js)))
It must be in the js_minifier class

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Sep 26, 2014

cc @raamdev I reviewed several JS compression alternatives available for PHP. The best available option at this time seems to be the Closure Compiler (powered by Google). Next would be the one we are using or JShrink. I prefer the modified copy of JSMin that we already use, over JShrink.

The Closure Compiler is not really a good option for us here, since it will require either:

  • A copy of Java on the server running the HTML Compressor.
  • A remote API connection (perhaps multiple connections) ~ too slow for our use case.

For these reasons, I decided to tweak the compressor we have now instead. I will keep my eyes open for other possibilities though (including writing one of our own).


In the mean time, I think I've found the cause of the most recent bug reports here. I will push the fixes referenced by the commits above into the next release of the HTMLC.

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Sep 26, 2014

@raamdev
Copy link
Contributor

@raamdev raamdev commented Sep 27, 2014

For these reasons, I decided to tweak the compressor we have now instead. I will keep my eyes open for other possibilities though (including writing one of our own).

Thanks for the heads up. It sounds like it might be best to go down the path of writing our own. Perhaps we can keep it modular enough to be shared with the open source community (and increase the chances of others contributing to improve it) and then include that module inside the HTML Compressor.

Version 140926 resolves these issues.

Thanks! I'll include this in the next Quick Cache update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants