Javascript Aggregator: Allowed memory size ... exhausted

Try using JSMIN. JSMIN+ has performance issues.

I have no explanation for a higher performance impact. The same versions of JSMIN and JSMIN+ are shipped with 6.x-1.5 and no changes to the way the minified files are built were made.

Maybe we should throw out JSMIN+ and instead support Googles Closure Compiler as suggested here: #632704: Support for google closure compiler

If JSMin+ does throw up, it's pretty horrible and hard to fix. You can disable it by running this query:

UPDATE [database].`variable` SET `value` = 'i:0;' WHERE `variable`.`name` = 'javascript_aggregator_jsminplus';

replace [database] with the name of your db.

Do we still need JSMIN+ then if its so buggy?

Just to say that I also had problems with JSmin+ and never got it to work properly. It would be great if you could implement google closure compiler.

Same problem. Reported to the JSMIN+ author here: http://crisp.tweakblogs.net/blog/1856/jsmin+-version-13.html#r_72741. As you can read there, I suspect it's because JSMIN+ has never been optimized to handle large JS files (such as the one Drupal generates due to JS aggregation).

Agreed that JSMIN+ should be removed until it is proven to be able to handle large JS files.

The author has responded:

It's actually PHP that consumes a lot of memory for array-like structures and the fact that JSMin+ first builds a full parse-tree before doing minification...

I asked him if no work-around is possible. Let's see what his answer to that is…

Answer given: http://crisp.tweakblogs.net/blog/1856/jsmin+-version-13.html#r_72887

So there's hope for a fix in the (near?) future...

Yep, there's hope! :)

Let's mark this as postponed for now then.

Related #780914: ran out of memory jsminplus.php

subscribe

subscribe, also interested in how this goes.

Why do we need JSMIN+? It seems to cause problems not solutions :)

@#15: Because it downsizes your JS dramatically. And since JS i highly used, it would be a great option.

I didn't see a BIG difference between JSMin and JSMin+

What dimensions are we talking about?

I think the summary of if it is JSMin just removes whitespace and shortens variable names
Where as JSMin+ parses the files which means you can do fancy programmatic things like removing duplicate functionality and rewriting code in optimal ways (both size and speed) like a compiler would as opposed to the human friendly readable solution
So yea, all in all code is a lot smaller and potentially faster as well

The solution to the memory exhausted problem is here: http://crisp.tweakblogs.net/blog/1665/a-new-javascript-minifier-jsmin+.h...

No patch to review.

Have you guys tried out mod_pagespeed?

http://code.google.com/speed/page-speed/docs/using_mod.html

I've installed it, but I haven't come to a good understanding of if this is a good mod to enable or not thus far.

unrelated comment in the wrong issue queue.

sorry about that! need to slow down.

issue is with cores jquery.form.js file. One needs to use a different file.
Alt is this new module: http://drupal.org/project/advagg
Still under heavy development but it is moving along.

Fwiw, I just upgraded ckeditor to v1.5 (from v1.4) on my site, and that started triggering these issues as well with jsmin+. I know they are not related, but someone else trying to understand why upgrading ckeditor breaks the site might find this useful. Before upgrading ckeditor, jsmin+ was not having these memory issues.

http://crisp.tweakblogs.net/blog/6861/jsmin+-version-14.html

Crisp (author of jsmin+)
so I decided to fix at least one other major problem that has been reported to me several times: the fact that JSMin+ was quite memory-intensive, especially when minifying large (eg combined) javascript files.

To fix that I moved part of the minification process to the JS parser itself where it can minify chunks of the parse tree which can be disposed after that. I made this change in such way that it is still possible to get a complete parse tree from the JS parser.

From a test I ran with the unminified source code of JQuery 1.6.2 memory usage went down from 40+MB to only around 8MB

Ooooh exciting, thanks for posting

Tried #27 and i no longer see WSOD page

sub

Agreed, the new version of JSMin+ fixes the WSOD issues.

Would be great to see this updated and released in a new version (or at least dev). All it takes is replacing the contents of jsminplus.php in the module with the newer version, available here (zipped):
http://files.tweakers.net/jsminplus/jsminplus.zip

If there needs to be a real patch, I can roll one, but this seems pretty straightforward...

FYI: WSOD is still possible, because jsmin+ is memory hungry. But, given the comment of the author (crisp) that memory consumption of minifying the source of jQuery 1.6.2 (~230KB) went down from +40MB to ~8MB (factor 5 at least), this would mean that:

• WSOD when minifying javascript larger than roughly 900KB (mem limit 32MB)
• WSOD when minifying javascript larger than roughly 1800KB (mem limit 64MB)
• WSOD when minifying javascript larger than roughly 3600KB (mem limit 128MB)

Taking into account Drupal's memory usage (estimated at ~10MB):

• WSOD when minifying javascript larger than roughly 700KB (mem limit 32MB)
• WSOD when minifying javascript larger than roughly 1600KB (mem limit 64MB)
• WSOD when minifying javascript larger than roughly 3400KB (mem limit 128MB)

All these numbers are order of magnitudes obviously (rough estimates).

Next steps would be to:
a) identify a representative max size of unminified (!!!), uncompressed (!!!) javascript aggregrate files
b) Determine if it's still likely that jsmin+ hits a reasonable memory limit and if so, which one (32, 64 or 128MB)
c) Depending on the memory limit, decide if jsmin+ can be included again, maybe with a disclaimer/warning if a mem limit higher than 32MB is required?

Just noting that JSMin+ *is* currently included. If we need to do more to establish when WSODs occur before including the newest JSMin+, I'd support removing it from the module and releasing a new version without it first -- because right now, with it present, it's basically unusable.

Err, you're right. So the maintainers can do:

a) remove jsmin+, do testing, add it back later if testing says so
b) upgrade, do testing, remove if testing says so
c) do nothing ;)

If you want js compression that uses the latest jsmin+ and testing of each file to make sure it is compressible then check out the Advanced CSS/JS Aggregation module.

That's great, but let's keep this issue queue on-task: Fixing this module.

Maintainers? Thoughts?

commited suggestion #31.