Re: Bits from the Testing Security team
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
Reply to: