A new compression algorithm to make Google Chrome updates small

The code has been available in their public SVN repository for quite some time:<p><a href="http://src.chromium.org/viewvc/chrome/trunk/src/courgette/" rel="nofollow">http://src.chromium.org/viewvc/chrome/trunk/src/courgette/</a><p>BTW, I've read about 40% of the Chrome code and I have to say it is the single best open-source project I've come to study so far. Incredibly clean code, really shows how much code reviews done properly can benefit project in the long run.

bsdiff was written by a HN regular, and I can't think of a better person to provide insight on this. (Hint.)

Does this generalize to a moving "fixed offset" in the compressor? i.e. can't it be done without the disassembler? (Assuming they're parsing x86?)<p>x86 is variable length, so this isn't trivial, but surely it is possible. I guess I don't like the "assembler" step because, hmm, SSE7 might not look like x86.<p>Also, if you were willing to have the loader to do the work, it sounds like you could do a -fPIC sort of thing, and load most code as a DLL.<p>Very cool that they got it working, though.

Without engaging conspiracy theories, I think the most interesting part is here:<p>The small size in combination with Google Chrome's silent update means we can update as often as necessary to keep users safe.<p>[An extra tidbit- courgette is a 'summer squash'. Silly Google...]

Technically, it's not a new compression algorithm. It's just a more efficient update scheme which uses a better suited binary diffing algorithm.

It's a very impressive achievment, but I'm not sure I buy their motivation for doing the work. 70k vs 700k? It's a blink of an eye on today's Internet. Sounds more like a very bright engineer wanted to work on a cool project, then reverse reasoned his way back to this "smaller is faster" idea.