Hi thron, thanks a lot for clarifying. Just dome more comments / questions:
thron7 schrieb: > On 04/27/2010 08:31 AM, Christian Schuff wrote: > >> Forgot to change the subject :/ Once again: >> >> Hi guys, >> >> I stumbled upon this really cool presentation: >> http://www.slideshare.net/nzakas/extreme-javascript-compression-with-yui-compressor >> > > I'm not familiar with the inner workings of the YUI compressor, but here > is my take from a qooxdoo perspective: > > >> It mainly points out how the developer can help the yui-compressor in >> achieving better compression rates by: >> - storing global variables, literals, property names in local variables >> > > That wouldn't help with qooxdoo. It's a good compression technique in > itself, as it allows you to refer to all of these - probably long - > identifiers by short variable names. Local variables are easy to > optimize automatically, and that's what the qooxdoo generator does as > well. But aliasing (that's what it is) global identifiers should IMO > *not* be done by the developer, as it obscures the code and makes it > harder to understand and maintain. It should also be done automatically, > and we might add this optimization in the future. > > That's being said, you might do these transformations by hand if you > wish, but I'm not sure whether you will introduce subtle effects that > defy the work of qooxdoo's dependency analysis (e.g. by passing aliases > to functions), which needs the global identifiers around to recognize > the dependency of a class to them. So I'd rather not recommend it. > > String literals are already optimized into local vars by qooxdoo's > string optimizer. I can't see much utility in optimizing other literals. > Property names are not optimized in qooxdoo. > Wouldnt the following example help the qx-generator shrink the function? I would guess something like that is not done automatically and I think its not to confusing for the developer as well. It would save some bytes in your build output and at the same time save some lookups. As long as you do not pass the local variables into other functions it neither obscures any dependencies? function toggle(element) { if (qx.bom.element.Class.has(element, ”selected”)) { qx.bom.element.Class.remove(element, “selected”); return false; } else { qx.bom.element.Class.add(element, “selected”); return false; } } function toggle(element) { var QBES = qx.bom.element.Class; if (QBES.has(element, ”selected”)) { QBES.remove(element, “selected”); return false; } else { QBES.add(element, “selected”); return false; } } > >> - limiting the use of var and return keyword to one for each function >> > > I doubt that this would speed up JS processing in the interpreters. > Condensing all var statements of a function into a single one again > saves some transfer size. But I think it would be a requirement too > harsh for a developer's coding style. It should, again, be done > automatically by the compression tool. > Does that mean the qx-generator is actually doing it? Or is it just a "should" :) Something like changing: var a = 0; var b = 0; var c = 8; into: var a = b = 0, c = 8; could be easily done. Things like var a = 0; if (something) { var b=19; ... some code ... } are a bit more tricky to optimize. Could make sense to do that optimization by scope. But I must admin that it might not save Gigabytes... :) >> As a qooxdoo developer I'm wondering >> 1. how far this hints do apply to the qx-generator as well? >> > > See above. > > >> 2. how far the framework classes follow those rules? >> > > The framework itself is written in a rather functional style, using > small functions with only few local variables which mostly work on > parameters and instance properties, so there is not much room for 'var' > squeezing. This might be different for applications, though. We don't > use aliasing of globals, but as I said I think this should be done in > the generator. Early returns from a function are used a lot. > > T. > > >> Cheers >> Christian >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> qooxdoo-devel mailing list >> qooxdoo-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > Thx Christian ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
