[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Module::CoreList and slow cme dpkg



Hello

I've run Devel::NYTprof on cme. To my surprise, the bad perf are mainly due to 
the fact that cme uses Module::Corelist to find if a perl dependency is a dual 
life package.

For instance, for libmodule-build-perl, cme will call 
 Module::Corelist::find_modules(/^module-build$/);

This call runs for roughly 8s. :-(

Currently, this regexp is required because of debian package naming 
convention: Module::Build -> libmodule-build-perl

In this case, finding the Perl module name from debian package name is 
straightforward. But that's not always the case, there are probably example of 
more creative capitalisation that cannot be infered from debian package name 
(although I lack actual example), like:

 ExtUtils::MakeMaker -> libextutils-makemaker-perl

I can see 2 ways to improve the perf of cme:

- Patch Module::Corelist to provide a translation hash from debian package 
name to Perl module name

- change cme to try a dumb (but fast) way to find the Perl module name from 
debian package name and add exceptions as they happen (I don't know how many 
actual exceptions one can find ...). This may lead to unpexpected changes in 
dependencies of your package if you are not careful.

I don't know which solution is better (or worse). It depends on the number of 
debian-perl package that are dual life *and* where the Perl module name cannot 
be inferred from Debian package name. 

All in all, patching Module::CoreList is probably safer even if we will change 
its behavior from upstream. I.e 'corelist libmodule-build-perl' will return 
something.

Thoughts ?

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


Reply to: