Community
Participate
Working Groups
Currently, we use the Python-based generator from the qooxdoo tooling to generate a precompiled Javascript file (client.js). A Java-based tool would be easier to integrate into our workflow and would make developers independent from qooxdoo and python.
I made up a test project that creates the client.js using the YUI compressor (http://yuilibrary.com/projects/yuicompressor/). Although the YUI compressor does not eliminate debug code, and does not inline strings, as the qooxdoo generator does, the resulting file is slightly smaller than the qooxdoo one. We'll now have to evaluate whether the YUI compressed code has any performance losses compared to the qooxdoo code. You can checkout the test project from Github: git://github.com/ralfstx/rap-clientbuilder.git
I did some tests with client.js compressed by Qooxdoo Tooling and Yahoo Compressor. Tests are done with Controls Demo under IE6 (Win XP), FF 3.6.10 (Win XP and Win 7), Safari 5.0.2 (Win 7), Google Chrome 7.0.517.41 (Win 7) and Opera 10.63 (Win 7). The memory consumption of the app with YUI compressed client.js is increased with less than an 1% in all browsers. Webkit-based browsers and Opera load the app with YUI compressed client.js faster than the one, compressed with Qooxdoo Tooling. FF and IE (including IE6) load it slower. But in all cases this deviation is very small - around 50ms-100ms. My personal conclusion is that, both versions perform the same - memory consumption and start-up time.
I changed the YUI-based JavaScript compressor to skip all conditionals of the form if( qx.core.Variant.isSet( "qx.debug", "on" ) ) { ... }, just like the qx generator does. The result is now more than 2.5% smaller than the qx-generated code. For me, there is also no measurable difference in load time between both variants on FF 3.6/Linux. Ivan, could you also test again? If your results are also good, then I think we can safely switch to the new compressor.
Ok, to sum up Ivans latest figures, we have: * Memory consumption: no clear results - sometimes slightly higher (< 1%), sometimes slightly lower (up to -4%) * Load time: faster in FF (-2%), Chrome (-3%), Safari (-5%), and Opera (-6%), but slower on IE (-6%) * I created another version of the YUI-based compressor that also cuts out irrelevant qx.core.Variant.select branches. This saves another 2% in size and probably also speeds up loading and improves memory consumption a bit. * It seems that IE (but only IE) benefits from replacing string literals with array references. Once we produce browser-specific client library versions, we could do the same. * Since the client.js is smaller than the old one the slightly longer load time on IE will be partly compensated when loaded from the internet. I think with these results, we can switch over to the YUI-based compressor. Any objections?
+1 form me.
I added two more optimizations to our new compressor: 1. Duplicated strings are now written into an array and the string literals are replaced by array references. It turned out that all IE versions benefit from this optimization. String literals that occur only once are not replaced. Interestingly, this technique significantly inflates the resulting code size. To optimize for size too, the compressor also skips those string literals that are too short, i.e. those that would inflate the resulting code if replaced. 2. Base calls are now rewritten in the same way the qx generator does: this.base( arguments, <args> ) becomes: arguments.callee.base.call( this, <args> ) This saves some function calls but slightly inflates the code (by ~3kB). I guess both is not noticeable. With these tweaks, I think we can eventually start creating the client.js using the new compressor. Replaced the client.js in CVS HEAD with a new one.
