Your message dated Fri, 20 Jul 2012 00:36:06 +0200
with message-id <[email protected]>
and subject line Re: Bug#676442: dpkg-vendor is slow
has caused the Debian Bug report #676442,
regarding dpkg-vendor is slow
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
676442: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676442
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.16.1.2ubuntu7
Severity: normal
File: /usr/bin/dpkg-vendor
Dear Maintainer,
dpkg-vendor is small useful program that is used by different other programs. It
should be fast, but actually is quite slow. 'dpkg-vendor --query Vendor' takes
40 ms on a recent fast machine (Core i5-2400S) with a hot cache and 230 ms on
an Intel Atom netbook.
As comparision, the Python version of distro-info took 28 ms, the Haskell
version 2.5 ms and the final C version only 0.7 ms on the recent fast machine.
distro-info probably has a similar complexity as dpkg-vendor and therefore
dpkg-vendor should be faster.
--- End Message ---
--- Begin Message ---
On Sat, 2012-06-16 at 16:59:03 +0200, Benjamin Drung wrote:
> Am Donnerstag, den 07.06.2012, 06:59 +0200 schrieb Guillem Jover:
> > On Thu, 2012-06-07 at 01:25:07 +0200, Benjamin Drung wrote:
> > > Package: dpkg-dev
> > > Version: 1.16.1.2ubuntu7
> > > Severity: normal
> > > File: /usr/bin/dpkg-vendor
> >
> > > dpkg-vendor is small useful program that is used by different other
> > > programs. It should be fast, but actually is quite slow.
> > > 'dpkg-vendor --query Vendor' takes 40 ms on a recent fast machine
> > > (Core i5-2400S) with a hot cache and 230 ms on an Intel Atom netbook.
> > >
> > > As comparision, the Python version of distro-info took 28 ms, the Haskell
> > > version 2.5 ms and the final C version only 0.7 ms on the recent fast
> > > machine. distro-info probably has a similar complexity as dpkg-vendor
> > > and therefore dpkg-vendor should be faster.
> >
> > On my system the following minimal test perl script takes (with a hot
> > cache) around 6ms:
> >
> > ,---
> > #!/usr/bin/perl
> > 1;
> > `---
>
> This takes 8.5 ms on my Atom netbook.
>
> > And the following one in contrast takes around 14ms:
> >
> > ,---
> > #!/usr/bin/perl
> > use warnings;
> > use strict;
> > 1;
> > `---
>
> This takes 18.4 ms on my Atom netbook.
My point was that just those take a significant amount of time on a
modern system. The rest of the “use” take much of the rest. Reducing
the time it takes might imply reducing modularity for example.
> > The call «dpkg-vendor --query Vendor» takes around 55ms.
> >
> > So, while this could certainly be improved in the perl code base, and
> > patches improving the performance would be appreciated, I'm honestly
> > failing to see how that's too slow really, or how this is something
> > that should distract attention from other things. If this script is
> > being called in a loop or a ton of times during the build process
> > then something is very wrong somewhere else, and the queried value
> > should get cached instead or something by the caller.
> >
> > Rewritting this in say C, does not seem either really appealing at this
> > point. Given the above I'm going to be marking this wontfix and closing
> > if no compelling reasons are given.
>
> debchange uses dpkg-vendor to query the vendor. «dch -e ''» takes 1.3 s
> with the query to dpkg-vendor and 1.1 s without that query. That's 15 %
> of the total execution time. Having a slow debchange is annoying. The
> time is accumulating if debchange is run multiple times (like in the
> test suite of devscripts).
It seems debchange has been changed to use the perl module directly,
which I guess reduced the time somewhat.
> dpkg-vendor should be fast to use in it bashrc or in bash completion
> code.
I don't see why, and it's not really outrageously slow in any case.
As said before, if you have concrete profiling data pointing to a
particularly slow codepath, suggestions for improvement or even better,
patches, I'm happy to take a look. Otherwise as mentioned previously
I'm just closing this now.
thanks,
guillem
--- End Message ---
