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)

History Show all quoted text
  Thu Jan 20 11:49:45 2011 kwilliams [...] cpan.org - Ticket created
Subject: Tests are pretty slow
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.
  Thu Jan 20 11:50:19 2011 kwilliams [...] cpan.org - Broken in 0.3607 added
  Mon Jan 24 21:00:43 2011 dagolden [...] cpan.org - Correspondence added
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.
  Mon Jan 24 21:00:44 2011 The RT System itself - Status changed from 'new' to 'open'
  Mon Jan 24 21:01:00 2011 dagolden [...] cpan.org - Severity Wishlist added
  Mon Jan 24 22:25:04 2011 kwilliams [...] cpan.org - Correspondence added
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.
  Tue Jan 25 18:03:58 2011 enobacon [...] gmail.com - Correspondence added
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>
# 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
  Sun Jan 30 08:01:40 2011 SREZIC [...] cpan.org - Correspondence added
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