If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

minify javascript files in release builds

RESOLVED WONTFIX

Status

()

Core
Build Config
RESOLVED WONTFIX
8 years ago
4 years ago

People

(Reporter: dietrich, Assigned: rflint)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ts])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
Keywords: perf
OS: Windows NT → All
Hardware: x86 → All
Whiteboard: [ts]
Taking to investigate what the potential win could be here.
Assignee: nobody → rflint
Status: NEW → ASSIGNED
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%)

Updated

8 years ago
Component: General → Build Config
Product: Firefox → Core
QA Contact: general → build-config
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.
Attachment #413058 - Attachment is obsolete: true
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.
(Reporter)

Comment 11

8 years ago
(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.
(Reporter)

Comment 14

8 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
I know this has been marked as WONTFIX, however, I wanted to share this article that I found showing that the code minified with YUI Compressor parses faster.

http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-load.html?v=2

I believe the focus is web based applications, but Firefox uses quite a bit of Javascript behind the scenes too, right?

Updated

4 years ago
Blocks: 903149
You need to log in before you can comment on or make changes to this bug.