On Fri, 23 Nov 2007, Aaron M. Ucko wrote: > dpkg-shlibdeps's latest incarnation (as of 1.14.8 and its experimental > predecessors) introduces a performance regression: it runs dpkg > --search once per executable or library being examined, rather than > caching its results any fashion. As each call requires scanning every > package's contents AFAICT, the resulting procedure can take a LONG > time on systems with many packages installed. (It would be great if > dpkg-query could itself run faster, but that's a separate issue.)
Somehow I was thinking I had implemented a cache but I must have mixed up with something else. Thanks for the check! > (At any rate, the rewrite at least resulted in much clearer and more > readily patched logic.) I did my best to make it understandable compared to the old code. :) > Could you please review and apply the attached patch (against 1.14.10) > when you get a chance? Applied. But it doesn't give a huge performance boost. On a run on kdemultimedia, it saves 8 seconds out of 3m12. I think we could save much more by caching the Dpkg::Shlibs::Objdump::Object objects created by the line: my $id = $dumplibs_wo_symfile->parse($lib); But optimizing this part probably needs somewhat more care and is a bit less straightforward. I also wonder how much memory it would cost on big packages. But if you have some time to spend on it, I'll happily review a patch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
