Saving even more bits

[Sandy McArthur]

I got the idea today to run GWTCompiler's generated JavaScript through
Dojo's ShinkSafe: http://alex.dojotoolkit.org/shrinksafe/

I ran some quick tests to see if it could improve on what GWT produces
and posted the results at:
http://spreadsheets.google.com/pub?key=pDH5-1uJePixOOg35G6fdEQ

The short version of the results is ShinkSafe reduced the size of
-style obfuscated by 93% and -style pretty by 76% for one of my test
apps. 7% could mean a second or two quicker load times for some people
and may be worth considering running GWTCompiler's output through
ShrinkSafe as the last step before creating the cache.html files.

[Scott Blum]

Interesting results. It looks like they were able to shrink it by
simply removing the newlines. When they didn't strip the newlines,
they actually *increased* the size of the code.

GWT currently produces newlines as a conscious decision. I'm not sure
how valid the reasons are, though. The first reason is we are under
the impression that some browser somewhere along the line didn't
handle astoundingly long lines very well and would actually have bugs
if you let the lines get "too long". But I don't know what browser
that was or if that's still valid. The second reason sounds amazingly
silly as I write it, but it was to make the obfuscated code easier to
debug. Without line breaks, if you tried to attach a debugger you'd
find you were always on line 1 and unable to step/breakpoint/etc. I
needed to have this to be able to debug the obfuscator's work.
Perhaps this is no longer valid either since the kinks seem to have
been mostly been worked out of the obfuscator.

Thoughts?
Scott

[Sandy McArthur]

When you gzip the -style obfuscated files the difference between what
GWT produces to the ShrinkSafe drops to 2.2%. Probably not worth the
benefit of keeping some newlines in there so you can do at least a
little on-site debugging.

Enabling no newlines must do some more stuff too because the source I
tested with only had 527 lines to start with but about 3K was trimmed
from the file size. I'm not aware of any EOL sequences that are 6 bytes
long. :-)

[Scott Blum]

On 1/12/07, Sandy McArthur <sand...@gmail.com> wrote:

> Enabling no newlines must do some more stuff too because the source I
> tested with only had 527 lines to start with but about 3K was trimmed
> from the file size. I'm not aware of any EOL sequences that are 6 bytes
> long. :-)

Well, "CR/LF" is 5 bytes. Maybe the slash is actually a Unicode character.

Scott

[Sandy McArthur]

:-)

I think I found where the 2.5K of bits comes from that isn't EOL:
unneeded white space around operators (=,+,-,*,etc).

If you change the calls to _parenPopOrSpace and _parenPushOrSpace in
JsToStringGenerationVisitor.visit(JsBinaryOperation) to calls to
_parenPop and _parenPush this saves almost 3K on the generated file
size. That would make GWT's output with newlines comparable to
ShrinkSafe output without newlines.

This change does cause problems with the "in" and "instanceof"
JavaScript operators because you can get code like "if(FOOinBAR)". My
hack of a solution to this was to pad spaces into the constant
declarations in JsBinaryOperator for INSTANCEOF and INOP. eg:

JsBinaryOperator INOP = create(" in ", 10, LEFT_INFIX);

Also this probably doesn't work when you have adjacent binary and unary
operators.
eg: "foo--bar" instead of "foo- -bar"

[Scott Blum]

Right. The devil is in the details, so we conservatively pad binary
operators right now. I have a todo item to go back and do this Right.
But if someone can do it in a way that can be shown to be correct,
that'd be great.

[Sandy McArthur]

Scott Blum wrote:
> Right. The devil is in the details, so we conservatively pad binary
> operators right now. I have a todo item to go back and do this Right.
> But if someone can do it in a way that can be shown to be correct,
> that'd be great.

I found that you can save ~6% on the file size by padding
UnaryOperators instead of binary operators. BinaryOperators are more
common and UnaryOperators only need a space on one side.

Needed changes are:
JsBinaryOperator: INSTANCEOF and INOP need spaces added to the ends of
the symbol string parameters.

JsToStringGenerationVisitor.visit(JsBinaryOperation): convert calls to
_parenPopOrSpace and _parenPushOrSpace to __parenPop and _parenPush.

JsToStringGenerationVisitor.visit(JsPostfixOperation): add a call to
_space() just before the return.

JsToStringGenerationVisitor.visit(JsPrefixOperation): add a call to
_space() at the start of the method.

[Scott Blum]

That sounds like a pretty safe solution. Can anyone else see any
problems with this approach?

Sandy, if you have a patch already for this solution, why don't you
submit a issue with it, and I'll look at it for 1.4.

Thanks,
Scott

[Sandy McArthur]

Scott Blum wrote:
> That sounds like a pretty safe solution. Can anyone else see any
> problems with this approach?

I thought maybe adjacent unary operators but the legal ones I can think
of work for me.
eg: "if (!--foo)" becoming "if (! --foo)"

> Sandy, if you have a patch already for this solution, why don't you
> submit a issue with it, and I'll look at it for 1.4.

http://code.google.com/p/google-web-toolkit/issues/detail?id=599

[Scott Blum]

Gracias!

On 1/16/07, Sandy McArthur <sand...@gmail.com> wrote:
>