String variables gets inlined producing bigger file than needed.

[blickly]

I'm currently working on a rather large script. That does allot of feature detection.
Most of the cases 
it checks if types are strings or objects. So storing common used "strings"
in variables would save 
bytes in my case. 

Imagine a piece of code like this:

(function(){
var FUNCTION    = "function",
    OBJECT      = "object";

    if( typeof Array.prototype == OBJECT ){
        alert(OBJECT);
    }

    if( typeof Array.prototype == FUNCTION ){
        alert( FUNCTION );
    }

if( typeof Object.prototype == OBJECT ){
        alert(OBJECT);
    }

if( typeof Object.prototype == FUNCTION ){
        alert(FUNCTION);
    }
})()

Closure compiles it to:
(function(){typeof Array.prototype=="object"&&alert("object");typeof

Array.prototype.slice=="function"&&alert("function");typeof

Object.prototype=="object"&&alert("object");typeof 
Object.prototype=="function"&&alert("function")})();

What is the expected output? What do you see instead?
(function(){var b="function",a="object";if(typeof Array.prototype==a){alert(a)}if(typeof

Array.prototype==b){alert(b)}if(typeof Object.prototype==a){alert(a)}if(typeof 
Object.prototype==b){alert(b)}})();

Original issue reported on code.google.com by V1@3rd-Eden.com on 2010-01-04 13:17:51

[blickly]

Your eyes deceive you! The actual output is both smaller  if you're using a decent 
web server. The web server should gzip the code when it sends it over the network.

Try gzipping the two code samples, and then comparing sizes.

See:
http://developer.yahoo.net/blog/archives/2007/07/high_performanc_3.html

It's hard to beat gzip. :)

Original issue reported on code.google.com by Nicholas.J.Santos on 2010-01-04 13:44:05

[blickly]

But than again, not everybody has gzip enabled: 
http://www.stevesouders.com/blog/2009/11/11/whos-not-getting-gzip/

Original issue reported on code.google.com by V1@3rd-Eden.com on 2010-01-04 13:53:24

[blickly]

True. But if you have gzip enabled, the web server should be smart enough to serve
the uncompressed version to users that don't support it. And i'm pretty sure that in
this case, making the gzip code bigger for 85% of users is a net loss.

I've also heard web server authors say that the 15% number is an overestimate. Many
setups will actually accept gzipped code served to them, even if they say they do not.

Original issue reported on code.google.com by nicksantos@google.com on 2010-01-04 14:11:11

[blickly]

I spotted an error in my expected output as there where some additional optimizes done.

(function(){var b="function",a="object"; typeof Array.prototype==a&&alert(a);typeof
Array.prototype==b&&alert(b);typeof 
Object.prototype==a&&alert(a);typeof Object.prototype==b&&alert(b)})();

Should be the expected code. And it actually still compresses to a smaller piece of
code.

Sure those stats should always be taken with a grain of salt. But gzip isn't everything.
And this optimize isn't providing that 
much additional gzip overhead. But it does take away allot of none gzip overhead.

Having that in mind and also the iphone cache limit. That has even be reduced to 15kb
(ungzipped size) for caching items. So 
I think that this something to be considered in future version of the compiler.

Original issue reported on code.google.com by V1@3rd-Eden.com on 2010-01-04 19:51:15