Front page | perl.perl5.porters |
Postings from February 2014
On Sun, Feb 02, 2014 at 09:30:49PM -0800, Tony Cook via RT wrote:
> On Fri Jan 31 03:31:05 2014, davem wrote:
> > Well, what's not clear to me is whether it's the windows system calls
> > that
> > have the big overhead, or perl doing stuff like UTF16 conversions. I
> > would
> > suspect the former.
>
> win32_stat() does a fair bit to try and emulate a POSIX stat() - including checking for the number of links and making sure file attributes are properly updated for hard links. Unfortunately, setting ${^WIN32_SLOPPY_STAT} to 1 in buildcustomize.pl didn't make much a difference in a rough build benchmark (from 712 to 697 seconds, which is probably just noise, considering I used the machine as my desktop.)
Sigh. And for most of this we don't need all of that.
The documented behaviour of _ (which I can't find!) is that it re-uses the
last stat buffer. Is the implementation such that this "last stat buffer" is
only the one used by PP filetest code? ie, if it *isn't*, then it seems
viable to replace many internal uses of stat in the C code with something
that isn't doing the full emulation on Win32.
I'm not sure what the cut off should be - looks like the require code in
S_check_type_and_open() is using stat to check the file permissions to
figure out the file type. I know that at least one place wants to know file
length. What is cheap to work out on Win32? And what needs lots of
emulation?
> > On UNIX, it is normal to run make with -j N, which will do a parallel
> > build, with make building up to N targets in parallel. So all the
> > parallelism is handled by make, not make_ext.
Yes, the extension build approach is quite different on *nix from Win32 and
VMS (and has been since both ports were added). make_ext.pl mostly merged
the behaviour of the *three* existing extension building tools, but retained
their calling conventions and uses. (There is only so much one can refactor
at once)
So on *nix, the (generated) Makefile contains a target for each extension to
be built, and all of those targets are dependency of "all". There are a few
pattern rules about how to build those targets (which use make_ext.pl), but
all the parallelism is handled by make.
> 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.
Nicholas Clark
Thread Previous
|
Thread Next