Re^2: gzseek for perl filehandles

Replies are listed 'Best First'.
Re^3: gzseek for perl filehandles by Anonymous Monk on Dec 23, 2010 at 15:58 UTC
File size is 1GB compressed: It's not words but phrases that I want to match against.	[reply]
Re^3: gzseek for perl filehandles by BrowserUk (Patriarch) on Dec 23, 2010 at 21:02 UTC
Googling `site:zlib.net rsyncable` turns up 0 hits?	[reply] [d/l]
Re^4: gzseek for perl filehandles by Corion (Patriarch) on Dec 23, 2010 at 21:18 UTC
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.	[reply] [d/l] [select]
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]