[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#554349: rred and stack overflows



2009/11/25 Robert Lemmen <robertle@semistable.com>:
> this is most certainly related to the way rred currently works, it uses
> a tail recursion on the stack to reverse the diff elements.
Really, i don't think it is a stackoverflow as it fails at a to prominent
cmd count... I have rewritten a few parts of rred to use long and more
sane return values and it patches the file now just fine. :)

While on it i have also integrated #463354 which will speed up the
patch-process a bit (but don't expect a miracle, the biggest timesucker
still is the decompression of the patches and applying them patch by
patch instead of concatenate the patches - but this has again a few
problems as this is far from a simple cat operation as you have to
recalculate line numbers)

> but i think the real problem is that we should never produce such
> a large diff anyway, downloading the original file is probably faster!
I will tell you a secret: For most users with fast connections pdiffs
are (always) slower. Pdiffs fight against download size and
decompression time of the Packages file, but if download time is
nearly zero for every download pdiff only competes with the compression
type: bz2 is slow, but pdiffs (if you need to apply more than one) are
most of the time slower (as you have a gzip decompression for
the patch and load and save of a uncompressed Packages file
for each patch). It is just that pdiffs are nicer for the mirrors,
everyone between the mirrors and your computer (e.g. ISP)
and the time of an "apt-get update" isn't a problem compared
to the rest of the upgrade progress for the casual user anyway -
and it is a great plus if you don't have a fast connection
(currently) or if you pay per traffic...

> perhaps we just need a filter on the diff generation side?
Michael has already a patch for apt to don't download the patch
if the patch is bigger than the actual file, so no need to implement
some logic in the generator as the file was itself correct, just to
big to be useful.


Best regards / Mit freundlichen Grüßen,

David "DonKult" Kalnischkies



Reply to: