optimizations regarding this ./. that

[Thomas Fischer]

Hi,
I made manually optimizations in my JS code by using a variable which references the context if there is havy usage of "this", like:

foo = function (x, y, z) {
  var that = this;
  that.x = 1; that.y = 2; that.z = 3
};

I expected that CC would compile it to

foo = function (x, y, z) {
  var a = this;
  a.x = x; a.y = y; a.z = z
};

but Closure Compiler disimprove the code to

bar = function (x, y, z) {
  this.x = x; this.y = y; this.z = z
};

Is der any chance to prevent this behavior - or the other way arround:
Could I spare these hand made optimization and CC would do this for me?

salute
Thomas

[Alan Leung]

Actually, because of the way gzip works, the code that closure compiler generated is more optimized when zipped.

-Alan

[Thomas Fischer]

Sure, but the client will unzip it and there is a difference to have 20,000 times "this" (8 Byte) or "a" (2 Byte) as source code in memory.
In havy used loops I stick on "this" to spare scope lookups for "a" (or is "this" also handled as variable(r/o)?)
In all other cases I prefer to have a variable to access the context.

salute
Thomas

[Alan Leung]

The answer to your question is no. There is nothing that can tell the compiler that.

Personally I would not worry too much about that neither. I would guess a decent Javascript parser / interupter / VM would keep a pool of string literals in the program and stores 20k pointers to "this" instead of allocating 20k "this" strings.

-Alan

 

salute
Thomas

[Thomas Fischer]

Hi,

> Personally I would not worry too much about that neither. I would guess a
> decent Javascript parser / interupter / VM would keep a pool of string
> literals in the program and stores 20k pointers to "this" instead of
> allocating 20k "this" strings.

<doubtingThomas>
I can't believe that even a decent browser will cut a script
source string into pieces of pooled strings.
</doubtingThomas>

It's not about how a VM stores *compiled* JS in memory. It's only
about the memorized real source code. The only disadvantage of using a
"this" reference variable could be the additional scope look up
(assumed that "this" is not a auto-inserted scope variable)

> The answer to your question is no. There is nothing that can tell the
> compiler that.

What a pity!

Is it possible to switch off CC's disimprovement (replacing "that"
with "this", see 1st message)?

salute
Thomas

[Nick Santos]

On Thu, Apr 28, 2011 at 11:56 AM, Thomas Fischer <fisch...@gmail.com> wrote:
> Is it possible to switch off CC's disimprovement (replacing "that"
> with "this", see 1st message)?

Closure: The Definitive Guide has a chapter on how to add custom
compiler passes without modifying the compiler source. You should feel
free to do this.

It is unlikely that we will be adding options to make code both larger
and slower, and we've done measurements that show this is what would
happen. :)

[Thomas Fischer]

> Closure: The Definitive Guide has a chapter ...

Thanks for the hint, I will try it.

> It is unlikely that we will be adding options to make code both larger
> and slower

I guess you measured the size of the gZipped source - but I talk about
client memory consumption (unzipped).
I'm aware that it will be slower (~ 0.0003 ms per "that"-access on my

machine) therefore I wrote:
> In havy used loops I stick on "this"

salute
Thomas