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 }
In what units are you measuring performance? I deduce it’s bytes in this case.
How about speed?
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.
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?
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
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.