this would reduce file io which could affect startup and snappiness on mobile especially. see bug 513132 for css compression, and bug 523479 for minifying js in extensions.
Taking to investigate what the potential win could be here.
Created attachment 413058 [details] [diff] [review] POC Went with Crockford's JSMin mainly because it doesn't introduce new build requirements, seems to produce fairly correct results and it's simple enough to not care what version of JS its working with. YUI Compressor and Closure Compiler simply roll over and die when attempting to minify our files (they're both Java and use Rhino - so maybe that's something we can work on). While JSMin seems to produce correct results, this patch currently yields a build that doesn't start up - so no perf numbers yet, but here's what it does for file sizes on a windows build: Components: - before: 1,829,719 bytes - after: 964,224 bytes (47%) browser.jar: - before: 2,608,081 bytes - after: 2,149,423 bytes (17.6%) toolkit.jar: - before: 3,035,515 bytes - after: 2,748,416 bytes (10%) Modules: - before: 342,743 bytes - after: 164,559 bytes (52%)
Created attachment 413792 [details] [diff] [review] POC v2 This fixes the startup issues and most things seem to work minus a single mochitest failure. The results from a try server run are somewhat expected: no discernible gains once fastload has been populated, but the startup on which that occurs appears to be around 100-200ms faster depending on the platform. I'll be doing a few more runs and tests locally to try and verify that.
The size win is really nice, but won't it make locating problems in the error console harder? And I didn't look further at the code, but does this also effect debug builds where having a minimal codesize is not necessary but rather having the exact code is more important?
Having this in place would have made finding and fixing large numbers of bugs extremely difficult. I think we should do this on mobile/wince only.
Can we address Dave's concern by hacking JSMin to never remove linefeeds (except for blank lines)? That would make the code still vaguely readable, and keep to one statement per line for debugging purposes. Gerv
(In reply to comment #6) > Can we address Dave's concern by hacking JSMin to never remove linefeeds > (except for blank lines)? That would make the code still vaguely readable, and > keep to one statement per line for debugging purposes. That sounds highly unpractical for JS files with thousands of lines.
I'm a little concerned about what effects this will have on error messages in the console as well. It could make finding JS errors quite difficult in release builds. Is the time-savings really worth it on desktop machines in this case?
Could we perhaps modify the way we jar the files so that it uses very low level compression? That would perhaps cut the IO down slightly at the expense of CPU during load, but given todays multi-core systems... that might be a good trade off. Bug 514083 is to that effect using file-system compression Mac OS X. Perhaps this would be for non-Mac platforms.
(In reply to comment #3) > The results from a try server run are somewhat expected: no > discernible gains once fastload has been populated, but the startup on which > that occurs appears to be around 100-200ms faster depending on the platform. Should we just WONTFIX this? I'd also expect fastload to negate any effects from minimization, and it sound like a lot of risk/complexity for a small first-run gain.
(In reply to comment #10) > I'd also expect fastload to negate any effects > from minimization Not all JS is fastloaded currently. However, the new startup cache will allow us to move more JS into fastload, so eventually yes this will be the case. At that point, minification will really only benefit the runs immediately after cache invalidation (install, updates). Yep, not sure it's worth the cost.
(In reply to comment #9) > Could we perhaps modify the way we jar the files so that it uses very low level > compression? That would perhaps cut the IO down slightly at the expense of CPU > during load, but given todays multi-core systems... that might be a good trade > off. Eh, mobile devices don't have oodles of CPU power to spare.
(In reply to comment #12) > Eh, mobile devices don't have oodles of CPU power to spare. True, but most Linux and Windows Desktops do.
the cost to debugging is too high, given the small set of circumstances in which this would actually help. better to focus on JAR compression. -> WONTFIX