evaluator can not be compressed due to some javascript syntax errors

[dyoo]

We're using certain identifiers that compressors like YUI compressor think are keywords.

These include:

throws

char (types.char) float (types.float)

If I replace these with types['char'] and types['float'], that should allow us to compress these files too.

Frankly, it doesn't help collections very much, at least through YUI compressor:

-rw-rw-r-- 1 dyoo nogroup 1036953 Jan 20 11:58 collections-min.js -rw-rw-r-- 1 dyoo nogroup 1165034 Jan 20 11:58 collections.js

It does cut down on the size of support.

kui ~/workspace/WeScheme/war/js/mzscheme-vm $ ls -l support.js ls -l support.js -rw-rw-r-- 1 dyoo nogroup 286413 Jan 20 12:02 support-min.js -rw-rw-r-- 1 dyoo nogroup 567610 Jan 20 12:01 support.js

Closure Compiler shaves support.js down to 247.52KB.

We should make changes to the runtime libraries so that we can compress these large files cleanly. We should do the same to codemirror.

[dyoo]

This will be fixed. Updated the build process so it automatically invokes the compiler.jar from Google Closure to make files smaller.

[schanzer]

Out of curiosity, what was the total compression savings, now that you've added in CodeMirror and everything else?

[dyoo]

Here are the minimized files:

-rw-rw-r-- 1 dyoo nogroup 969058 Jan 20 13:48 ./mzscheme-vm/collections-min.js
-rw-rw-r-- 1 dyoo nogroup 275207 Jan 20 13:48 ./openEditor/openEditor-calc.js
-rw-rw-r-- 1 dyoo nogroup 254734 Jan 20 13:48 ./mzscheme-vm/support-min.js
-rw-rw-r-- 1 dyoo nogroup 175502 Jan 20 13:47 ./console-calc.js
-rw-rw-r-- 1 dyoo nogroup 46991 Jan 20 13:48 ./codemirror2/lib/codemirror-min.js
-rw-rw-r-- 1 dyoo nogroup 14571 Jan 20 13:47 ./view-calc.js 
-rw-rw-r-- 1 dyoo nogroup 5531 Jan 20 13:48 ./codemirror2-contrib/scheme2/scheme2-min.js
-rw-rw-r-- 1 dyoo nogroup 5160 Jan 20 13:48 ./mzscheme-vm/evaluator-min.js

The minimized files total 1746754 bytes.

I can compare vs the size of the related files before compression:

-rw-rw-r-- 1 dyoo nogroup 1165034 Jan 20 14:01 mzscheme-vm/collections.js
-rw-rw-r-- 1 dyoo nogroup 970729 Jan 20 17:02 openEditor-calc.js
-rw-rw-r-- 1 dyoo nogroup  567610 Jan 20 14:01 mzscheme-vm/support.js
-rw-rw-r-- 1 dyoo nogroup 649336 Jan 20 17:02 console-calc.js
-rw-rw-r-- 1 dyoo nogroup  112373 Dec  9 17:21 codemirror2/lib/codemirror.js
-rw-rw-r-- 1 dyoo nogroup  55132 Jan 20 17:02 view-calc.js
-rw-rw-r-- 1 dyoo nogroup   18365 Dec  2 14:10 codemirror2-contrib/scheme2/scheme2.js
-rw-rw-r-- 1 dyoo nogroup   13426 Jan  8 16:55 mzscheme-vm/evaluator.js

Uncompressed, they total 3552005 bytes.

So overall we're getting around a 50% savings.

[schanzer]

Wowza. That's a big payoff for load time over 3G. I wonder if it doesn't also make sense to combine the static files, to reduce HTTP requests?

[dyoo]

I don't think we can bundle pngs, which make up the majority of the other files served for a request. I do confirm that caching appears to happen between requests, so once a user visits WeScheme once, the subsequent visits are a lot faster.

[schanzer]

Interesting - when I load WeScheme on Chrome, I see more requests for .js files than for .pngs, and the the js loading eats up the majority of the load time. I suppose we could just load ONE png, and use CSS clipping to chop it into the images we want. Google uses this same approach on their homepage.

Let me know if you think this is worthwhile, and I'll make the file and CSS rules for it.

Emmanuel Schanzer

Bootstrap Program Director 617-792-2438 schanzer@bootstrapworld.org

On Jan 23, 2012, at 12:05 AM, Danny Yoo wrote:

I don't think we can bundle pngs, which make up the majority of the other files served for a request. I do confirm that caching appears to happen between requests, so once a user visits WeScheme once, the subsequent visits are a lot faster.

---

Reply to this email directly or view it on GitHub: https://github.com/dyoo/WeScheme/issues/43#issuecomment-3609301