[plt-scheme] Compression dictionary

2009/10/5 Eli Barzilay <eli at barzilay.org>:
> On Oct  5, Jens Axel Søgaard wrote:

>> Is it possible to make a back-of-the-envelope calculation with
>> respect to compression rate, download time, and decoding time?
>
> Heh -- you could -- but the critical point here is is (I think) not
> the download time, but the time it takes the browser to parse the 3mb
> file and execute it to get the vector of data into memory.

Okay, then it is irrelevant whether gzip the server uses gzip or not.

>> Question: Does the PLT web server support on-the-fly gzip
>> compression?
>
> I don't think so, but that's a side-issue, since I'm dealing with
> static files that are being served through apache (as does
> docs.plt-scheme.org).

> To clarify, the problem I'm tackling is the javascript index used for
> searching -- the one you get if you go to docs.plt-scheme.org/search/
> or if you do a search from drscheme.  It's basically the delay you get
> when you open the search -- which includes both the network time and
> the JS execution time, and if you do it locally then it's all just JS
> time.

Hmm. Tricky.

You said that LZW worked best on large text, but that you couldn't
afford large strings. Is it an idea to build a dictionary on the server,
by running the LZW compression algorithm on all the strings
(thus having a large text), and then start the LZW decompression
with a non-empty dictionary?

There is a trade of between the time to download the dictionary
and the time won by starting with a better dictionary involved.

-- 
Jens Axel Søgaard