Comments on: Microsoft Ajax Minifier VS YUI Compressor

By: BertrandLeRoy

BertrandLeRoy — Wed, 20 Jan 2010 22:07:12 +0000

Aha, seems like spammers finally figured out how to circumvent Ajaxian’s extremely advanced CAPTCHA ;)

By: InfinitiesLoop

InfinitiesLoop — Thu, 22 Oct 2009 21:51:57 +0000

Yup — when not using the HC option, it would definitely be an improvement to convert foo["bar"] to foo.bar. When using HC, well, use with care, and understand the implications. And always check the gzipped result since that is what matters most — it would be a nice feature, actually, if the tool could do that for you.

By: webreflection

webreflection — Thu, 22 Oct 2009 20:44:51 +0000

@InfinitiesLoop it makes access dynamic due to variable assignment while YUI Compressor understands unnecessary literals and it strips out unnecessary chars as well. In both case I hope we agree that there is a property access change, and that is what I wrote.
We should remember that most libraries are inside a big closure loads of nested scopes. A dynamic access to the top closure variable to discover a static literal is, in my opinion, not worth it, performances speaking, but it could save a couple of bytes.
Thanks in any case for explanation, I guess if you had to provide one, this point was not perfectly clear. Regards

By: InfinitiesLoop

InfinitiesLoop — Thu, 22 Oct 2009 19:26:26 +0000

The Ajax Minifier does not convert property access into dynamic access — that doesn’t seem very clear here. If you have foo.bar=baz, it does _not_ convert it to foo[a]=baz. What it does do is alias literals, so if foo["bar"] = baz is converted to foo[a]=baz it’s only because “bar” was a literal that was used enough times for that to save space, it has nothing to do with changing how property access occurs. That does incur a slight performance penelty vs. foo["bar"]. Whether that is enough to matter for your scenario is up to you — it’s not even the default option.

By: webreflection

webreflection — Thu, 22 Oct 2009 08:55:01 +0000

@shadedecho I am not talking about o["a"] VS o.a, which I suppose is almost the equivalent for every JS engine and/or optimized run-time, I am talking about o[a] VS o.a
If there is a variable there is no guarantee that variable is the expected string. A variable needs to be “discovered” in the current scope and it should be a primitive “string” or an instanceof String, or whatever Object with a valueOf or a toString call, do you follow me?
A simple example is an Array loop, where arr[i] will point to a different value and “i” is a primitive “number” (int)
Even in a small block, with or without “let” scope, rather than “var”, “i” needs to be discovered and its value needs to be assigned for that moment.
This is the reason extreme optimizations over loops use direct access if the length is reasonable (arr[0], arr[1], arr[2], arr[3]) avoiding both dynamic access and integer incrementation (++i)
Moreover, if we have o["a"] more than twice, let’s say 3 times, the variable declaration plus square brackets will cost more bytes rather than less (var a=”a”;o[a];o[a];o[a]; VS o.a;o.a;o.a;) and being unnecessary, plus forcing the dynamic access, do we agree YUI Compressor provides a better solution here? That is my point about performances and dynamic access, fine sometimes, but not necessary better :)

By: shadedecho

shadedecho — Thu, 22 Oct 2009 06:26:44 +0000

@webreflection — why does it need to cast as a string if it’s already a string?

I understand that [a] is two operations (in general) versus one operation for .abc. But doesn’t that then mean that ["abc"] should just be the same as .abc?

And if that’s true, it would seem like engines like TraceMonkey (and perhaps others) should be able to tell if the variable being used for the property lookup is, in effect, a “constant”, meaning it is used as an l-value only once, in its initial declaration/assignment, and isn’t changed throughout the code. If they could tell that, couldn’t they pre-optimize code execution for the use of “constants” for property lookup, and skip all the variable lookup and casting junk, making [a] equivalent roughly to .abc?

I ask this because I find it quite a useful technique to turn repeated property references into [a] style with constants, for the purposes of compression. It’s troublesome that this trades file size reduction for a performance hit. With minification so prevalent, I would think it would be becoming a common enough thing that the JS engines should be looking to optimize for it.

By: webreflection

webreflection — Wed, 21 Oct 2009 20:56:49 +0000

@shadedecho from parsing point of view you need to retrieve the variable, its value eventually “casted” as string, and only after access the property name if any. These are 3 operations rather than just 1: access the property name if any. In this case we can spot static strings concatenations possibly replaced by variables, then concatenated, and only after the property name will be known. YUI Compressor does something clever and it is almost the same SpiderMonkey engine does if you create a Function(“o”, ‘return o["key"]‘) it will be created as return o.key which is more direct and logical.

By: shadedecho

shadedecho — Wed, 21 Oct 2009 12:38:55 +0000

Something I don’t understand:

var a = “abc”;
b[a] = 123; // less efficient?
b.abc = 123; // more efficient?

Seems like accessing the property with [] would be roughly the same as accessing it with a . operator.

By: ywg

ywg — Wed, 21 Oct 2009 09:33:47 +0000

@Stephen Walther

Sorry to say things like that, I don’t wan’t to degrade the quality of your (and Microsoft Dev Team) work…
But on this particular point I had a really hard time believing this is just an “accidental regression” and not a corporate decision. Either you don’t support them at all and strip them out, or you just leave them as they are.
But not understanding that “conditionnal” stands for “print on certain conditions”… no I don’t buy this.

By: anoncoward

anoncoward — Wed, 21 Oct 2009 07:08:34 +0000

The multitude of options don't exactly inspire confidence, but I'm sure MS will reduce them in future versions. Who needs IE specific compression these days? The MSBuild integration is a rather nice feature, but the .NET port of YUI Compressor also does that very well. What's more it allows to combine files in addition to compressing them.

By: rasmusfl0e

rasmusfl0e — Wed, 21 Oct 2009 01:01:06 +0000

String concatenation to build property names?! Nice try – but incurring a performance penalty in return for a minimaly faster load doesn’t do it for me. That feature should be killed of ASAP.

I’ll stick with YUI – at least it doesn’t mess with my code.

By: swalther

swalther — Tue, 20 Oct 2009 21:15:20 +0000

@ywg — Really, there is no evil conspiracy here on the part of Microsoft :) We’ve been using the Microsoft Ajax Minifier for several years to minify the JavaScript files in the Microsoft Ajax Library and the AJAX Control Toolkit. Because we found the tool to be so useful internally, we wanted to share it with the community.

There are a number of interesting suggestions in the article. For example, we do have to look at supporting conditional-compilation comments and the of /*! … */ comment notation for a future release.

One thing that the article above did not mention is that the Microsoft Ajax Minifier includes an MSBuild task that you can use to minify your JavaScript files when using Visual Studio automatically. If you want to read a more in-depth description of the Microsoft Ajax Minifier, see my blog post at:

http://stephenwalther.com/blog/archive/2009/10/16/using-the-new-microsoft-ajax-minifier.aspx

Thanks for the article.

— Stephen Walther (Microsoft Ajax Team)

By: leptons

leptons — Tue, 20 Oct 2009 21:07:49 +0000

I tested compressing a 944KB javascript source file using both YUIC and the new MS AJAX compression tool.

YUIC output = 565KB
MS AJAX Minifier output = 533KB

so, MS wins here, but when I ZIP’d the files up it turns out like this:

YUIC output zipped = 112KB
MS AJAX Minifier output zipped = 114KB

I’m still going to use YUIC considering the GZIP’d results for YUIC are smaller after being zipped.

By: ajpiano

ajpiano — Tue, 20 Oct 2009 20:50:31 +0000

great information in the article. i am not sure why it has not been edited for basic grammatical errors to increase readability.

By: ThomasHansen

ThomasHansen — Tue, 20 Oct 2009 20:07:42 +0000

@ywg
If you need another approach, you might want to check out Kariem’s nAnt Build task for miifying and gunzipping as part of an nAnt build script …
http://ra-ajax.org/custom-nant-jsmin-task-for-minifying-javascript-files.blog
.
and
http://ra-ajax.org/webresource-axd-and-javascript-gzip-compression-a-simple-solution.blog
.
We’re using it in Ra ourselves …

By: ywg

ywg — Tue, 20 Oct 2009 19:00:15 +0000

The conditionnal comment semi-removal, is a very obvious attempt to break compatibility with other browsers.

I can understand that microsoft tries to push his software, but delibirate attempt to break his users’ software is unaceptable.

The string accessor optimisation is a good idea in theory, but anyone coming from a javascript/actionscript (or any interpreted language) knows that string concatenation and objects lookup are a performance issue.
I’m not even sure this is worth it, considering than the LZ77 algorithm in Gunzip should reduce theses string.

Numbers and brackets optimisation are pretty cool.