Modestas Vainius wrote: > If debhelper program has nothing to do, it will exit fast. Slow down should > be > minimal.
There is some potential for speeding up dh. Josh Tripplet and I once discussed: * Having dh optimize out calls to debhelper commands that will be no-ops. For a subset of commands, this can be determined just by looking for their config files. Some kind of metadata would be necessary for dh to tell which commands are in that subset. * Make dh run debhelper commands directly in one perl process, rather than through exec. (However, I think this is unlikely to be worth the insanity.) * Writing a faster parser for simple command-line options. Benchmarks show that parsing options is 50% of the overhead of running no-op debhelper commands. This is because if there are options, it loads Getopt::Long, which is slow. This overhead is particularly bad when dh needs to pass -i / -a to all commands, which otherwise would need no options. * Removing calls to dpkg-architecture from dh_auto_configure and dh_auto_build when they will not actually be configuring or building. * Speed up dh_gencontrol, er, I mean dpkg-gencontrol, which by itself is responsible for more than 1/3 of the total runtime of dh binary in a package where the other debhelper commands are all no-ops. -- see shy jo
signature.asc
Description: Digital signature
