Re^4: gzseek for perl filehandles

This seems very weird. Google shows some basic idea from 1999 and some patches to gzip/zlib later, but they don't seem to have it made into gzip or zlib, at least I find no mention of it in any Changes file or, again, via Google.

Comment on Re^4: gzseek for perl filehandles Select or Download Code

Replies are listed 'Best First'.
Re^5: gzseek for perl filehandles by BrowserUk (Patriarch) on Dec 24, 2010 at 00:31 UTC
It 1999 paper certainly made it seem like it was something well worth pursuing. At least for rsync purposes. But I think the Anonymonk (OP?) that brought the subject up has the wrong end of the stick. From my reading, the resetting of the dictionary when the rolling checksum rolls over allows rsync to be more efficient by breaking the breaking the compressed file into smaller, separately decompressable chunks. But unless the mechanism also stored the (uncompressed) offset of each of those chunks, then it wouldn't help gzseek be more efficient. It would still need to decompress every chunk serially to work out the start offset of each chunk. I guess if it stored the offsets on the first run through, it would save a bit of time on subsequent seeks. But even with a full table of chunk offsets, random access would still be horribly slow. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^5: gzseek for perl filehandles
by BrowserUk (Patriarch) on Dec 24, 2010 at 00:31 UTC

It 1999 paper certainly made it seem like it was something well worth pursuing. At least for rsync purposes.

But I think the Anonymonk (OP?) that brought the subject up has the wrong end of the stick.

From my reading, the resetting of the dictionary when the rolling checksum rolls over allows rsync to be more efficient by breaking the breaking the compressed file into smaller, separately decompressable chunks.

But unless the mechanism also stored the (uncompressed) offset of each of those chunks, then it wouldn't help gzseek be more efficient. It would still need to decompress every chunk serially to work out the start offset of each chunk. I guess if it stored the offsets on the first run through, it would save a bit of time on subsequent seeks. But even with a full table of chunk offsets, random access would still be horribly slow.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]