Compression IN JavaScript (not OF JavaScript) | January 10th, 2008
So I was looking into in-browser compression for my RobotReplay work..
This is actually a really hard thing to Google because of the confusion with gZipping JavaScript resources for lower file sizes on the web. That particular problem is easy to solve and commonplace. What’s really unique and interesting to me are the applications of gZipping content in JavaScript for offline storage or delayed transmission, or for compressing Ajax requests over an uncompressed connection. It could also be a little useful for the purposes of encoding your data from prying eyes.
Why we might want to perform gZip compression in a JavaScript program:
- Reduce data footprint before storing in offline storage (IE UserData, Flash SharedObject storage, sessionStorage, globalStorage, Google Gears, etc etc) since all of these have limits to how much you can store.
- Reducing bandwidth requirements for transmitting large amounts of data via an Ajax or cross-domain XHR request.
I can’t think of any others right now but I found this showing a working proof of concept of LZ77 (gZip) compression in JavaScript. There are some ‘catches’, however.
This was only really useful if you are compressing large-ish amounts of data (10K+) or the benefits derived from compression don’t outweigh the costs, which are: larger footprint for your JavaScript program, the inherent hassle of dealing with compressed data, and also performance.
Also, this proof of concept really illustrates how SLOW JavaScript is in general. Even compressing small amounts of data can take several seconds. So I wanted to find a better way to do this. So I worked on finding another (better) way to compress the data.
Then I had an idea.. what about using Flash to do the same thing and then use ExternalInterface to marshal between your JavaScript program and the Flash movie? It was worth an experiment.
So here is a demo showing compression of text data using the same algorithm in JavaScript and AS2 (Flash 9) via external Interface.
Note: in the chart below, smaller is better.
Again the demo is here: http://blogs.nitobi.com/alexei/demos/compression/index.htm
Download the source here: http://blogs.nitobi.com/alexei/demos/compression/nitobi_js_compression.zip
January 11th, 2008 at 4:16 am
Wow – surprising hey. I’m consistently unimpressed by Flash’s AS performance. There’s no reason the External Interface technique can’t be a smoking gun for processor intensive JS requirements. Did you benchmark the mere process of getting that much data into and then out of the Flash runtime?
January 11th, 2008 at 4:19 am
ps – I got a javascript error on the flash demo.
January 11th, 2008 at 3:33 pm
Oops. Sorry. The demo is fixed now.
That’s what I expected too. I thought we’d for sure get a performance boost by doing it Flash. As yet I have not benchmarked the performance of moving the data in and out but I should do that so see how it’s contributing.
May 22nd, 2008 at 2:51 am
the real bitlength of compressed lorem ipsum example is about 1/3 (not 2/3) smaller than the original text. and even that is only because repeatedly copy pasted parts of text. there is not much use of putting more one-byte chars in one utf char, other than saving space in textarea field. (or am i wrong?)
i was just playing around with your script really exited about the idea of compressing client to server ajax or similar traffic, even made a decompresser for utf8 strings in php.. ehh but then looked at php strlen of compressed utf8 text and it is even larger than the original.
but this is a cool and fast tool to obfuscate data.
or was this article about flash vs js performance ;D
May 22nd, 2008 at 6:56 pm
actually i was wrong. in the previous post. appologize. do not “moderate” it. i made it work good for utf8 input data by flattening the string to byte sequence (splitting the morethanonebyte chars to seperate ascii chars). good. i can post the solution some time if someone is interested – still working on it.
May 25th, 2008 at 6:32 pm
Hey kajs,
Would be interested to see your solution. That was a good point actually about the strlen.
July 1st, 2008 at 9:46 pm
Hey,I think this is quite an interesting idea. But could you explain deeply how the flash work with javascript ? Also, in what way flash could improve the performance?
July 1st, 2008 at 10:45 pm
Hey getter3,
To communicate with flash via JavaScript you have a couple options.. one is to use ExternalInterface and the other is to use FABridge (which also uses external interface). You can basically call flash functions from JavaScript and vice versa.
Flash should be much better than browser-based JavaScript at doing large amounts of computation – like calculating fractals, compressing/uncompressing, encoding/decoding video, etc. This is because a lot of Flash code is compiled to byte-code at runtime and run in the most CPU efficient way possible. I spoke to one of the Flash engineers for V9 once and he was showing me an ActionScript FOR loop with the byte code equivilent, and it was almost the same number of lines of code – really stunning.. However, for whatever reason, in this case Flash is underperfoming pure JavaScript for this particular task, and I’m curious why.
October 1st, 2008 at 8:49 am
Hi,
Theres some problem with the demo.It is not working on IE.