[Laszlo-dev] application/lfc file size

André Bargull andre.bargull at udo.edu
Wed Aug 27 17:30:01 PDT 2008


The code-expansion in "dataBindAttribute" is the 
"setAttribute"-inlining. That is made by purpose to improve performance.
But that snippet shows some other optimization points:
- the "is"-test could be optimized away, because "Function" will never 
have a "$lzsc$isa"-method (same goes for LzEvent) (this is LPP-6692)
- the "ondatapath" variable is quite long ("$lzsc$1375182235"), possible 
to use a shorter form?
- the compiler should know that there is a setter for "datapath" defined 
in LzNode, this setter could be called directly

Concerning LPP-6017: the original changeset may work, if there is a 
possibility to add certain properties early enough to the 
LzNode-instance (primarily functions). That way, the LzDelegate bug 
should go away (LPP-6370).


> Some initial thoughts:
>
> In LzNode.lzs, dataBindAttribute(),
> this:
>
>      if ( !this.datapath ){
>        this.setAttribute('datapath', ".");
>      }
>
> Is translated to:
>
> if(!this.datapath){
> if(!this.__LZdeleted){
> if(Function["$lzsc$isa"]?Function.$lzsc$isa(this["$lzc 
> $set_datapath"]):this["$lzc$set_datapath"] instanceof Function){
> this["$lzc$set_datapath"](".")
> }else{
> this["datapath"]=".";var $lzsc 
> $1375182235=this["ondatapath"];if(LzEvent["$lzsc$isa"]?LzEvent.$lzsc 
> $isa($lzsc$1375182235):$lzsc$1375182235 instanceof LzEvent){
> if($lzsc$1375182235.ready){
> $lzsc$1375182235.sendEvent(".")
> }}}}}
>
> I wonder if we could improve this by using some global helper functions:
>
>      if ( !this.datapath ){
>        $lzsc$Util.setAttribute(this, 'datapath', ".");
>      }
>
> or even:
>
>      if ( !this.datapath ){
>        $lzsc$Util.setAttribute(this, 'datapath', "$lzsc$set_datapath",  
> "ondatapath", ".");
>      }
>
> If we could do the former, we might get a savings of 250 bytes per.
> There are at about 40 occurrences of this code.  10K savings.
> Not huge, but maybe this sort of simple technique can be
> applied in other situations.
>
> For example, there are 85 occurrences of something like this in the LFC:
>
>    (arguments.callee.superclass? 
> arguments.callee.superclass.prototype["$lzsc 
> $initialize"]:this.nextMethod(arguments.callee,"$lzsc 
> $initialize")).call(this,$1,$2,$3,$4)
>
> Maybe something like:
>
>    $lzsc$Util.superFcn(this, "$lzsc$initialize", arguments).call(this, 
> $1,$2,$3,$4);
>
> Another 6K savings.
>
> ================================================================
> Common subexpressions (CSE) elimination:
>
> I think about 42K of the LFC (347K) is strings.
>    $ grep '"'  LFCdhtml.js | sed -e 's/^[^"]*//' -e 's/[^"]*$//' -e  
> 's/"\([^"]*\)"[^"]*/"\1"/g' | tr '"' '\012' | grep . | sort | wc -c
>    42509
>
> About 24K of that is unique:
> $ grep '"'  LFCdhtml.js | sed -e 's/^[^"]*//' -e 's/[^"]*$//' -e 's/"\ 
> ([^"]*\)"[^"]*/"\1"/g' | tr '"' '\012' | grep . | sort | uniq | wc -c
>    24300
>
> So 18K of strings are redundant (used more than once).
> When strings are used more then a couple times, a variable could
> be used.  This could happen automatically (recognizing it in the
> compiler), or looking for extreme cases and fixing them manually.
>
> ================================================================
> Wacky CSE idea #1
>
> There are lots of occurrences of 'this.', for example this.foo,  
> this.bar().
> When we see a lot of these in a function, could set $1 = this;
> and then use $1.foo instead of this.foo.
> With 4400 occurrences in the LFC, that saves us up to 8K bytes.
> I know, it's wacky.
>
> If it's done in the compiler, it would be the first step for more
> sophisticated CSE elimination  Finding commonalities like:
>     this.foo.x, this.foo.bar
> and setting a common variable $1 = this.foo .
> ================================================================
> There are some commentary here about how things got larger and
> some attempts to fix things:
>
>     http://www.openlaszlo.org/jira/browse/LPP-6017
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda at ddanderson.com
> www: http://www.ddanderson.com




More information about the Laszlo-dev mailing list