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

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

Thread Previous | Thread Next
Nicholas Clark
February 28, 2014 15:47
Re: [perl #121119] [PATCH] speed up miniperl @INC searching,buildcustomize
Message ID:
On Tue, Feb 04, 2014 at 02:35:23PM -0800, Tony Cook via RT wrote:
> On Mon Feb 03 23:34:31 2014, bulk88 wrote:
> > 1. disabling pmc in miniperl can be done for all OSes, there is also
> > the PERL_IS_MINIPERL macro, so no need to -D it
> Not trivially, platforms which use Makefile.SH use the same pp_ctl$(O) for both miniperl and the final perl.
> We'd need to what's done with op.c/opmini.c and perl.c/perlmini.c, and I don't think it's worth it.

I'm not convinced that it's worth it either, given that

1) unlike Win32, it's not trivial to do this due to the re-use of pp_ctl$(o)
2) there doesn't seem to be any noticeable speed hit on *nix

> > 2. ${^WIN32_SLOPPY_STAT} for Win32 miniperl only
> > 
> > 3. /lib first on Win32 miniperl only

These seem reasonable, but I don't even know how to do the first, so don't
know how easy it is. The latter *is* easy, but it's 90% testing, which I can't
do either.

On the subject of testing (that I can't) as George's smoker is unhappy again,
could someone on Win32 try out the branch smoke-me/nicholas/fake-pm_to_blib
and verify that it still builds on Win32? (I think that it should work)
It avoids the entire use of ExtUtils::MakeMaker and make for building about
80 of the "simple" pure-perl modules, so it should speed things up.
Based on the experience of disabling PMCs, I hope that on Win32 it's quite a
bit faster.

> I considered if for non-sloppy stat, if the CreatFileA() fails, we should just shortcut to win32_stat() failing.  But that won't work for directories.

The other thought that I had is that the whole investigation with require
showed that a lot of the slowness on Win32 is caused by doing emulation work
that gets thrown away.

Because the internals were originate on Unix they assume that all file
metadata comes from a stat() call, hence you can't get any metadata without
a stat() call, hence there's no real need to think of anything "smaller" than
a stat() call, so just make a stat() call then pick out the part you need.

That's clearly not the case on Win32, where emulating parts of the data
stat() returns is possible, but expensive. So the result is that the
"portable" C code happily makes a stat() call, based on the assumptions
above, the stat() emulation code works hard, because it doesn't know the
context, and then the caller throws the work away.

I think it would be useful if someone would audit all the internal uses of
stat(), to see what fields are actually being used. From this, it's probably
going to be obvious that the PerlLIO_stat()/PerlLIO_fstat()/PerlLIO_lstat()
macros should be augmented, maybe with 2 more calls to directly get just
length, and "mode", or maybe something else (like a sloppy-stat(), which
is documented to be guaranteed to only fill in the cheap subset of the stat
structure, and does just that on Win32)

This feels like it might make a small general speedup for Win32.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About