[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