develooper Front page | perl.perl5.porters | Postings from February 2014

[perl #121119] [PATCH] speed up miniperl @INC searching, buildcustomize

Thread Previous | Thread Next
From:
Tony Cook via RT
Date:
February 4, 2014 03:02
Subject:
[perl #121119] [PATCH] speed up miniperl @INC searching, buildcustomize
Message ID:
rt-4.0.18-19481-1391482937-1094.121119-15-0@perl.org
On Mon Feb 03 01:41:14 2014, nicholas wrote:
> > dmake (the tool, not our dmake makefile) supports parallel builds,
> > but from discussing this on IRC, it's not practical since MSVC will
> > attempt to lock the common PDB file and abort if it fails to do so.
> >
> > Maybe a flag to skip checking for .pmc files would help, but I
> > wouldn't expect require's .pmc checks to be a noticable timesink for
> > typical usage.
> 
> I was going to suggest this. IIRC on the Win32 build there's a
> complete set
> of objects compiled for miniperl, with "bootstrapping" C compiler
> flags, and
> a complete second set compiled for the installed perl, with user
> chosen flags.
> 
> (Unlike *nix and VMS, where most objects are re-used for both)
> 
> If I have that correct, I'd suggest adding -DPERL_DISABLE_PMC to the
> flags for building miniperl on Win32. It's a simple change, doesn't
> affect
> any installed code, and it should speed things up a bit.

This made a significant difference, I did 3 runs for a baseline, with build durations of 718, 735 and 727 seconds[1].

I added -DPERL_DISABLE_PMC to the $(MINICORE_OBJ) build command and did another three runs with durations of 643, 698 and 675 seconds.

Taking the median of each that's a 7% reduction in build time.

Tony

[1] this was on my normal desktop, which didn't have a lot of CPU usage, but I guess there was a lot of noise anyway.

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121119

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About