SlimIt vs YUI Compressor

by Ruslan Spivak on January 15, 2012

Let’s compare compression of SlimIt and YUI Compressor using jQuery source file.

File SlimIt SlimIt+gzip YUI YUI+gzip
jquery-1.7.1.js 97241 33330 104684 36164

As you can see SlimIt performs better and it’s pure Python.
Do you still use YUI Compressor in your Python project? Give SlimIt a try.
If you have any questions or encountered any issue here is the place to discuss it: GitHub Issues

If you enjoyed this post why not subscribe via email or my RSS feed and get the latest updates immediately. You can also follow me on GitHub or Twitter.

{ 5 comments… read them below or add one }

Craig McQueen January 16, 2012 at 5:12 PM

In what units are you measuring performance? I deduce it’s bytes in this case.

How about speed?

Reply

Ruslan Spivak January 16, 2012 at 8:50 PM

That’s right Craig – it’s bytes.

As for speed SlimIt right now is the slowest among YUI, Google CC, and UglifyJS.
I compared SlimIt and YUI speed compression with JQuery source file and SlimIt is roughly 2-2.5 times slower on my machine when launched on the command line.
Once the project is feature complete I’ll devote time to optimize the compression speed. Currently it’s a low priority feature.

Reply

Rick van Hattem January 18, 2012 at 7:33 AM

A few other important questions are:
– is the compression guaranteed to work (i.e. not break js)
– will it impact the rendering speed for the browser (like packer does)
– js only or also css like yui?

Reply

Ruslan Spivak January 18, 2012 at 8:03 AM

Hey Rick,

1. Unfortunately I can’t guarantee that it’s bug free. With my limited use of jQuery 1.6.2 and jQuery Flot library I had no issues. I also know SlimIt was used to minify code generated by pyjs/pyjamas and the issues found were fixed. SlimIt also comes with a pretty extensive test suite too. The more people use the library, the more issues get found and get fixed. If you hit a snag with it I’ll try to fix the problem ASAP.
2. Could you elaborate on the packer issue?
3. It’s JS only

Reply

Hasan Yasin Ozturk February 4, 2012 at 12:30 PM

From my extensive tests, it does not break the code. It is much better than other packers for many situations.

If the packer you mean is http://dean.edwards.name/packer/ then slimit is better for safety of the resulting code at least for the extent I have tested both. As it is already stated here:
http://dean.edwards.name/weblog/2007/04/packer3/
it breaks code if you do things like
if (b) {
while (n[i++] < 0);
}
which it translates as
if(b){while(n[i++]<0)} //which is a syntax error.
slimit makes it smaller and _correct_:
if(b)while(n[i++]<0);

I added another statement inside if to see:
if (b) {
a=5;
while (n[i++] < 0);
}
packer breaks it the same way, while slimit keeps both curvy parentheses and also the semicolon which is the best that can be done:
if(b){a=5;while(n[i++]<0);}

As for the runtime performance, if it is what you mean with rendering speed of the browser, of course shorter code is faster to parse; but the issue here is over-advertised by library developers. Having a smaller code file to download is good for cost and time to start running the code. When download is done, if you are not using 200-character-long local variable names, no library can make it faster. It is simply marketing. The things that Google's closure and some other libraries try are dangerous, as they clearly state. I should code well myself instead of expecting some speed-ups from a compiler.

Reply

Speak your mind

Previous post:

Next post: