Re: Couple of patches
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Russ Allbery wrote:
>> More detail would be good. The only things that level 1 unpack of
>> binary packages generates are the control directory and index, the file
>> indices, and the breakdown of the package control information, plus a
>> symlink.
> The fields don't seem to be used by any collection script except for
> diffstat, all the other collection scripts "use" them just to make sure
> they were run on the right directory, something I believe is not very
> likely to ever happen; and it would be easy to notice it.
Right, but they're used by the check scripts all over the place. Moving
that code into a collect script makes some conceptual sense, but it's not
going to be an optimization; the script will be run anyway.
> The generation of index and index-owner-id is a bit suboptimal, only one
> call to dpkg-deb is needed. The tar file could be stored in disk (or
> left in memory, but the idea is to avoid the call to dpkg-deb which will
> just spawn at least two more processes) which should perform better
> because the file would remain in the cache.
It would surprise me if this would help. Writing the tar file out to disk
is a bunch of additional disk writes that we currently don't have to do,
and the deb file that's being processed should already be in the file
cache, so writing out a separate tar file is actually going to make
caching behavior worse. I expect the writes to have more impact than a
couple of processes. I'm not positive, though.
> I could probably spend some time on this. Also, as I demonstrated above,
> it could be better if the two unpack scripts were merged to optimise the
> whole process. Would you, or anyone else, have any objection on moving
> towards this idea? If there's none, I could do it in a couple of hours,
> including testing.
I think it's important that any changes preserve the current lab structure
and either make the code generally simpler or produce a measurable
performance benefit. I don't really want to trade code complexity for
performance unless the performance gain is substantial. If you have
changes that fit those requirements, sure, that's fine.
> http://perldoc.perl.org/perlfaq3.html#How-do-I-profile-my-Perl-programs%3f
Oh, Devel::DProf. Excellent, thanks!
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: