Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 64964
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: kwilliams [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.3607
Fixed in: (no value)



Subject: Tests are pretty slow
Download (untitled) / with headers
text/plain 231b
The regression tests for Module-Build do take a while, especially t/compat.t . It's kind of a drag. Last time I benchmarked (which was at least a couple years ago), it seemed to be spending a long time doing cwd() or something.
Download (untitled) / with headers
text/plain 417b
On my system, tests run in just over 1 minute. I'm not sure what exactly changed in t/compat.t, but I know I've fixed (personally or applied patches for) lots of M::B::Compat bugs over the last couple years. It's one of my big annoyances that I spend so much time maintaining API compatibility with the thing that M::B replaces. It's possible that t/compat.t is slower just because of much improved test coverage.
Download (untitled) / with headers
text/plain 354b
Yeah, I agree - a similar annoyance is that it spends so much time *testing* MakeMaker compatibility. When I did a Devel::NYTProf profile just now, 93.4% of the time of compat.t was spent in CORE::system(). FWIW, I recently switched Path::Class to Dist::Zilla and I'm *very* impressed - I doubt I'll ever use compatibility mode in M::B again myself.
Subject: Re: [rt.cpan.org #64964] Tests are pretty slow
Date: Tue, 25 Jan 2011 15:03:44 -0800
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 937b
# from Ken Williams via RT # on Monday 24 January 2011 19:25: Show quoted text
>When I did a Devel::NYTProf profile just now, 93.4% of the time of > compat.t was spent in CORE::system().
IIRC, it runs the full "perl Makefile.PL; make; make test" on many different scenarios, so almost everything is going to profile as CORE::system() - you would need to profile one level lower to find the bottleneck, which I'm guessing is overhead of directory setup and teardown for each scenario, including recreating the Build.PL, makefile, module files, etc. I looked at breaking this into smaller tests which could be parallelized, but never got it done after some refactors to the test libs. Also, compat.t is somewhat futile as a developer test, since good coverage of this actually requires multiple systems and configurations, so it would be much better to remove it from t/ and instead have a CI process keeping an eye out for breakage. --Eric
Download (untitled) / with headers
text/plain 599b
On 2011-01-20 11:49:45, KWILLIAMS wrote: Show quoted text
> The regression tests for Module-Build do take a while, especially > t/compat.t . It's kind of a > drag. Last time I benchmarked (which was at least a couple years > ago), it seemed to be > spending a long time doing cwd() or something.
I also find the MB test suite slow, but it's caused by other test scripts on my system: install.t, ppm.t, manifypods.t. I looked into the first two with truss, it seems that all installed .packlist files are inspected. Probably the slowness is proportional to the number of installed modules. Regards, Slaven


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.