Raphael Geissert <atomo64+deb...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
