Re: These new diffs are great, but...
- To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
- Cc: Marc Haber <mh+debian-devel@zugschlus.de>, debian-devel@lists.debian.org
- Subject: Re: These new diffs are great, but...
- From: Florian Weimer <fw@deneb.enyo.de>
- Date: Sun, 20 Aug 2006 17:57:03 +0200
- Message-id: <[🔎] 874pw7s8mo.fsf@mid.deneb.enyo.de>
- In-reply-to: <871wsxvbft.fsf@informatik.uni-tuebingen.de> (Goswin von Brederlow's message of "Fri, 07 Jul 2006 14:36:38 +0200")
- References: <20060629180509.GB1986@yi.org> <20060629183541.GA11648@piper.madduck.net> <20060629183836.GA5061@uio.no> <20060629184345.GG1986@yi.org> <E1FwC3l-0002TZ-P2@scyw00225.scy001.de> <20060630091037.GA13596@rotes76.wohnheim.uni-kl.de> <E1FwJCZ-0006yZ-JA@scyw00225.scy001.de> <87hd22sj2j.fsf@mid.deneb.enyo.de> <871wsxvbft.fsf@informatik.uni-tuebingen.de>
* Goswin von Brederlow:
> What code do you need there? If the rred method keeps the full Index
> file in memory during patching it can just be fed all the patches one
> after another and only write out the final result at the
> end. Combining the patches is a simple cat.
#383881 suggests that I/O bandwidth is not the issue. In fact, if you
keep the file in memory and repeatedly patch it, you won't get away
from the O(n*m) complexity (n being the file size, m the number of
hunks in the patches), or whatever complexity it is. Shuffling
pointers instead of full lines only saves a constant factor, which
might not be enough.
However, patching rred to apply patches in a single run would be a
good start because all further optimizations will need it.
Reply to: