Switching From YUICompressor to Closure Compiler Using ANT <apply>

On 15/11/09 15:38, Thomas 'PointedEars' Lahn wrote:

Stefan Weiss wrote:
If size is the metric we're optimizing for, then JS minimization + gzip
compression will produce smaller files than gzip alone (obviously).

If you think that would be obvious, you have not understood gzip.

I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files. It's theoretically possible to construct
JavaScript files in such a way that their minified versions will lead to
worse overall compression, but that has no practical relevance.


cheers,
stefan


PS: Here's a trivial example:

$ echo -n 'if(foo)alert("bar")' > test.js
$ yuicomp test.js > test-min.js
$ gzip -c test.js > test.js.gz
test.js: -10.5%
$ gzip -c test-min.js > test-min.js.gz
test-min.js: -9.1%
$ ls -lA
total 16K
-rw-r--r-- 1 user user 22 2009-11-15 16:08 test-min.js
-rw-r--r-- 1 user user 54 2009-11-15 16:08 test-min.js.gz
-rw-r--r-- 1 user user 19 2009-11-15 16:08 test.js
-rw-r--r-- 1 user user 47 2009-11-15 16:08 test.js.gz

The minified version is larger than the original (the YUI compressor
adds curly braces and a semicolon), and the compressed versions are even
larger. Like I said: it's possible, but not relevant.

Stefan Weiss wrote:

Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
If size is the metric we're optimizing for, then JS minimization + gzip
compression will produce smaller files than gzip alone (obviously).
If you think that would be obvious, you have not understood gzip.

I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files.

You will have to prove that.


PointedEars

On 15/11/09 16:28, Thomas 'PointedEars' Lahn wrote:

Stefan Weiss wrote:
Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
If size is the metric we're optimizing for, then JS minimization + gzip
compression will produce smaller files than gzip alone (obviously).
If you think that would be obvious, you have not understood gzip.

I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files.

You will have to prove that.

Prove what? I just gave you an example where the minimized version was
larger after compression. I also explained that I'm talking about
real-life usage, not academic experiments. This situation is
sufficiently unlikely to occur that it is practically irrelevant.

If you think it isn't, and if you're correct, you'll have no trouble
finding a more realistic counter example...


cheers,
stefan

Stefan Weiss wrote:

On 15/11/09 15:38, Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
If size is the metric we're optimizing for, then JS minimization
+ gzip compression will produce smaller files than gzip alone
(obviously).

If you think that would be obvious, you have not understood gzip.

I'm not talking about edge cases. Source files where all comments

Removing comments is likely to make a difference, but source files do
not necessarily contain comments (and it is reasonable to remove
comments for distribution and leave the rest of the structure intact in
order to avoid the need to significantly regression test the
post-compression source code).

and unnecessary white space and punctuation

Removing unnecessary whitespace is not necessarily going to have that
much impact. Zip compression likes to act on repetition and patterns of
whitespace around javascript tokens can be just as repetitious as the
same tokens with the unnecessary whitespace removed.

have been removed will result in
smaller compressed files.
snip

The thing that doesn't make sense to me is that the difference between
the eventual zipped versions with and without the javascript
minification tends to be extremely small (with the zipping providing the
largest size reduction regardless of anything else), and that doesn't
quite justify the (cost of the) extra QA stage of verifying the
post-minification code. Of course, organisations like Google, who don't
do any real QA, won't see the implied cost.

Richard.

Stefan Weiss wrote:

On 15/11/09 16:28, Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
If size is the metric we're optimizing for, then JS minimization +
gzip compression will produce smaller files than gzip alone
(obviously).
If you think that would be obvious, you have not understood gzip.

I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files.

You will have to prove that.

Prove what?

Your argument.

I just gave you an example where the minimized version was larger after
compression.

<http://en.wikipedia.org/wiki/Proof_by_example>

also explained that I'm talking about real-life usage, not academic
experiments.

And that is probably <http://en.wikipedia.org/wiki/Appeal_to_the_majority>.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On 15/11/09 16:49, Richard Cornford wrote:

Stefan Weiss wrote:
I'm not talking about edge cases. Source files where all comments
[snip]
and unnecessary white space and punctuation

Removing unnecessary whitespace is not necessarily going to have that
much impact.

Maybe not much, but "a+b" still compresses better than "a + b". You'll
typically get these cases several times per line. It adds up.

The thing that doesn't make sense to me is that the difference between
the eventual zipped versions with and without the javascript
minification tends to be extremely small (with the zipping providing the
largest size reduction regardless of anything else), and that doesn't
quite justify the (cost of the) extra QA stage of verifying the
post-minification code.

I don't agree that the size difference is "extremely small". I just
confirmed this (again) on four relatively large files (concatenated
scripts which are actually deployed like this). Here's what I get:

orig min gzip min+gzip
--------+-------+-------+----------
230K 72K 58K 27K
378K 125K 84K 42K
441K 152K 99K 50K
149K 55K 27K 17K

Whether this size reduction is worth the extra effort is not something
that can be decided in general, without any knowledge about the project.


cheers,
stefan

I see now that I forgot something.

Stefan Weiss wrote:

This situation issufficiently unlikely to occur that it is practically
irrelevant.

I am not sure what kind of fallacy this is, but it is one.

If you think it isn't, and if you're correct, you'll have no trouble
finding a more realistic counter example...

This one is obvious again:
<http://en.wikipedia.org/wiki/Shifting_the_burden_of_proof>


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On 15/11/09 17:17, Thomas 'PointedEars' Lahn wrote:

I see now that I forgot something.

Yes, your argument. If all that's coming from you is lists of real or
imagined logical fallacies, I'm not interested in continuing this
conversation. Can we get back on topic?


cheers,
stefan

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> writes:

Stefan Weiss wrote:

I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files.

You will have to prove that.

Removing just comments will definitly give a smaller result for any
reasonable and general compression strategy. Comments (non-trivial
ones, at least) contain information, and unless you have a
pathological example, it's information that's unlikely to also occur
in the remaining code. It will cause extra bits in the resulting
compressed data.

Whether removing whitespace and punctuation makes a difference isn't as
obvious, but it's very unlikely to make the result larger (as in: If you
can find a case where it does, please show us).


More generally: consistently and structurally removing characters from
a file is unlikely to make it compress worse. What you are removing
will not increase the total information entrophy of the data. It is
important that the removal is consistent (otherwise the pattern in
where something is removed will itself carry information).

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

[I originally sent this one p.m. by mistake, my apologies]

On 15/11/09 17:01, Thomas 'PointedEars' Lahn wrote:

Stefan Weiss wrote:
On 15/11/09 16:28, Thomas 'PointedEars' Lahn wrote:
Stefan Weiss wrote:
I'm not talking about edge cases. Source files where all comments and
unnecessary white space and punctuation have been removed will result in
smaller compressed files.

You will have to prove that.

Prove what?

Your argument.

I just gave you an example where the minimized version was larger after
compression.

http://en.wikipedia.org/wiki/Proof_by_example

Does not apply. Please read what I actually wrote: I said *larger* after
compression. That's a counter example against what I originally wrote,
and one "black swan" is all it takes.

also explained that I'm talking about real-life usage, not academic
experiments.

And that is probably <http://en.wikipedia.org/wiki/Appeal_to_the_majority>.

Absolutely not. Did you actually read that article or just its title?


cheers,
stefan