Closed
Bug 73256
Opened 24 years ago
Closed 24 years ago
[RFE] crunch JS files before packaging milestone releases
Categories
(SeaMonkey :: Build Config, enhancement, P5)
SeaMonkey
Build Config
Tracking
(Not tracked)
VERIFIED
INVALID
Future
People
(Reporter: dev+mozilla, Assigned: cls)
References
()
Details
(Keywords: perf)
For Milestone releases, the JS files that Mozilla uses should be crunched with
the JavaScript Crunchinator (see URL), thus eliminating unnecessary whitespace &
comments. This will increase performance.
Reporter | ||
Updated•24 years ago
|
Severity: normal → enhancement
Keywords: perf
Summary: crunch JS files before packaging → [RFE] crunch JS files before packaging
Reporter | ||
Comment 1•24 years ago
|
||
See http://www.mozillazine.org/talkback.html?article=1867&message=28#28 for
discussion about this.
See also bug 68045 "precompile chrome JS and load it incrementally".
Why not make a perl script that runs before making the jar files? This will save
download time, runs faster and uses less memory.
How badly would this "crunchinator" reduce the readability of the js files?
Brendan, any thoughts? If it were enabled, it wouldn't be just for milestone
releases. It would be for all builds (or maybe all non-debug builds).
Priority: -- → P5
Target Milestone: --- → Future
Chris, please forget readability. In fact the Brainjar "crunchinator" makes the
source completely unreadable (after running it, you won't be able to read the
source because this crunchinator makes one long string. But start thinking in
kilobytes because I saved 49.5% on a single javascript!
Comment 6•24 years ago
|
||
Disk is cheap, some people value readability much more than the savings lost if
we don't crunch. I'm not going to make that call -- cc'ing ben, hewitt, et al.
for their thoughts.
I do think the cycle savings will be minor, and I would require someone to show
before and after wall-time and quantify measurements of startup, first-window,
etc. We don't recompile chrome JS for second-window-of-same-class when we're
brutally sharing. What's more, I have a bug I'm working on to precompile JS
into a fast-load format on first-run-since-install. I just am not convinced
that this crunching is worthwhile, apart from space savings on disk, which are
worth very little.
/be
Asa: what's the target audience of milestone releases?
I think it would be ok if we supported dropin file preprocessing (which
included chruninator) and perhaps we could have the xpi dists use it, but the
monolithic builds should not have this. My theory is that people who download
monolithic builds are willing to take the extra download time.
The other question i have is how do chrunched files fair after zipping?
Summary: [RFE] crunch JS files before packaging → [RFE] crunch JS files before packaging milestone releases
would it be possible to have 2 versions of the file?
One where the coding is done and readability is important, and the other one
which will be created by taking the full file and crunching it during the build?
The second file should probably go into a separate directory...
Of course one should first see, how much time is saved and if it is worth the
trouble...
Comment 9•24 years ago
|
||
just listening in ... adding cc:
also, just wanted to say i crunch my JS code sometimes and have saved more than
50% in file size (no joke, recently went from 8K --> 4K and 6K --> 2K on some
linked .JS files) ... now obviously, that's a huge savings while talking about
downloading code over a dial-up connection ... NOW granted, i don't know what
that would mean in terms of Mozilla and code sitting on disc and performance ...
in terms of readability, yeah it sucks, but in the end i just keep a working
copy and during the build process then i crunch it .....
Comment 10•24 years ago
|
||
hmmmmmmm .... also, could apply to all .CSS files and maybe any other files
(xul? -- not an XML guy, don't know) and whatever else where whitespace doesn't
matter .... ?
Comment 11•24 years ago
|
||
And this could be nearly useless, please report numbers for sizes after
zipping.
Comment 12•24 years ago
|
||
timeless:
we are talking about performance, which might be improved, if the parser has not
to wade through known useless code.
After zipping the difference between the original and the crunched files should
hardly be noticable.
Comment 13•24 years ago
|
||
yeah, i'm not that concerned with dowload times ... i'm thinking parser
performance when loading the thing ....
Comment 14•24 years ago
|
||
Ok, if this is just performance, then let's resolve this as wontfix+useless and
just focus on bug 68045
Comment 15•24 years ago
|
||
yes, I have to agree that the parser really doesn't spend that much time "wading
through known useless code"..
I think that the crunchinator was designed to make js quick to DOWNLOAD - over a
slow link, dropping 6k to 3k could mean the difference of 1-2 seconds in
displaying a page. We're reading these files right off of disk, I don't think
that parsing the comments/whitespace is really a big deal.
Comment 16•24 years ago
|
||
until someone posts numbers on crunched vs. non-crunched builds, this is all
speculation.
The only advantage I've seen so far is in download size (definitely a concern of
Netscape as one of the 5 S's touted in Netscape 6), but since the js will all be
in compressed files already for download that doesn't buy us much. The real win
for this bug will be if someone can show crunched js runs consistently,
measurably faster than uncrunched. If it's faster, we can make it happen in the
release builds.
Comment 17•24 years ago
|
||
ok, you all are the experts on opening files, reading them into memory, etc. so
whatever can be done to speed it up great ... 68045 sounds like it's definately
got more support until someone can prove that this type of thing would
contribute something of value ...
Comment 18•24 years ago
|
||
(Only commenting on the _download_ size issue ... we can shrink comm.jar by
88KB just by stripping out the MPL from the 223 files in comm.jar that have it
(yeah, I actually measured this :-). If done for all jars, this may be ~250KB,
which is a minute of download time for a dialup user. The build folks may wish
to do this although it probably needs a separate bug. (I'm assuming that a
single license in the top level of a single jar file would be enough to satisfy
legal requirement)).
Comment 19•24 years ago
|
||
I personally am OK with the idea of stripping out the MPL verbiage in order to
create the jar file. (I think this came up before in some context -- maybe
with XUL files?) I see this as no different than stripping out
license-related comments in compiled C/C++ -- the jar file as distributed (with
license notices stripped out or compressed) is essentially in "executable" form
compared to the original source files. I think leaving a single license notice
in the jar file (for all files) is OK -- presuming (an important point!) that
all the files in the jar file are in fact under the same license.
Comment 20•24 years ago
|
||
we should probably implement about:npl, about:mpl, and about:license first -- i
don't remember the bug id.
Comment 21•24 years ago
|
||
First, I assume we're talking about the notice ("This file is governed by the
terms of the MPL ...") and not the license itself. There's no question about
the latter, the license itself does not belong here.
I'm generally unhappy with the idea of files that don't have any license notice,
and we can't pull these out for source releases. But I agree with Frank that it
can be done for the executables. And timeless is right, we should also make
sure the the notice about the MPL is visible and easy to find.
Comment 22•24 years ago
|
||
First, I assume we're talking about the notice ("This file is governed by the
terms of the MPL ...") and not the license itself. There's no question about
the latter, the license itself does not belong here.
I'm generally unhappy with the idea of files that don't have any license notice,
and we can't pull these out for source releases. But I agree with Frank that it
can be done for the executables. And timeless is right, we should also make
sure the the notice about the MPL is visible and easy to find.
Comment 23•24 years ago
|
||
we should file a separate bug on the license removal to avoid confusing it with
JS crunching.
Comment 24•24 years ago
|
||
filed bug 73661 for the narrower issue of just stripping the notice, in favour
of a single notice within the '.jar' file.
Comment 25•24 years ago
|
||
See also bug 68686 which has numbers on compressed vs. uncompressed .jar files.
We could save 530K on download by having UN-compressed jars because when the
uncompressed .jar is compressed into the .xpi package zip is able to squeeze
out the redundant license headers etc. which it isn't able to do when
XUL/JS/etc is compressed on a file-by-file basis.
The minor downside is that chrome would take up an extra 3.6 Mb on the user's
disk, and more seriously could possibly be a lot slower to load since more has
to be read from disk.
Comment 26•24 years ago
|
||
hmmmm ..... did i read that right?
yikes, i'd take a bigger download over larger disk space and longer load time
any day. i guess that was the whole point.
Comment 27•24 years ago
|
||
I just vote for timeless suggestion to invalidate this bug in favor for bug
68045. After fixing 68045 (precompiling) the end user of a binary would get the
same files, since comments / whitespaces do not influence the compiled code and
we can avoid a lot of work with handling compressed / uncompressed source files.
Comment 28•24 years ago
|
||
YES
Comment 29•24 years ago
|
||
> We could save 530K on download by having UN-compressed jars because when the
> uncompressed .jar is compressed into the .xpi package zip is able to squeeze
> out the redundant license headers etc. which it isn't able to do when
> XUL/JS/etc is compressed on a file-by-file basis.
> The minor downside is that chrome would take up an extra 3.6 Mb on the user's
> disk, and more seriously could possibly be a lot slower to load since more has
> to be read from disk.
But it doesn't have to be uncompressed which would offset the slowdown.
Reporter | ||
Comment 30•24 years ago
|
||
Ok, marking INVALID due to bug 68045.
Reporter | ||
Comment 31•24 years ago
|
||
Really doing so this time.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•