On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote: > Nico Golde writes ("Re: Bits from the Testing Security team"): > > quoting Adam Heath from #debian-devel: > > Thanks for passing that on. > > > 2007-10-15 18:07 <eigood> dpkg's configure has an option for using > > shared libraries or static linking > > 2007-10-15 18:08 <eigood> for gzip, it can do a static library link, > > a dynamic library link, or a runtime > > fork/exec of gzip > > 2007-10-15 18:08 <eigood> afaicr, when I did the patch > > 2007-10-15 18:10 <eigood> the real reason, is dpkg used to only > > fork/exec gzip > > 2007-10-15 18:11 <eigood> for efficiency, I gave it an option to > > link to zlib > > This reason doesn't make sense because it's not more efficient. It > saves about two fork/execs per package, which is not a significant > part of dpkg's execution cost. > > Indeed on modern multicore systems running the decompression in a > separate process allows it to be run on a separate CPU, in parallel to > the other processing done by dpkg proper. So it might be faster. > > (I haven't done any benchmarking but I think these conclusions are > pretty obvious.)
Decompression is typicly something that is i/o bound, not cpu bound. What I think running it in a separate process does it creating 2 pipes you don't need. You can just do everything in the local memory of 1 process. Anyway, like you said, someone needs to do benchmarks to see if either solution is faster than the other. I'm not convinced either way. > Having dpkg invoke the decompresser as a separate program provides > several IMO important advantages. It simplifies the code in dpkg, and > it greatly simplifies the management of cross-version compatibility > and multiple optional decompression schemes (including experimental > ones), by decoupling dpkg from the decompressers. I see no reason why we can't have both available. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]