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 22:35
Subject:
[perl #121119] [PATCH] speed up miniperl @INC searching, buildcustomize
Message ID:
rt-4.0.18-20453-1391553322-735.121119-15-0@perl.org
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.

> 2. ${^WIN32_SLOPPY_STAT} for Win32 miniperl only
> 
> 3. /lib first on Win32 miniperl only
> 
> The reason I/O is slow on the machine I used is probably a combination
> of 2 things. A horrible HP RAID controller I've never figured out why
> its slow. Sequential read speed averages 49 MBps. Random access time 8
> ms. But its full of 15K SCSIs. And I'm using WOW64 (32 bit Windows
> process on 64 bit OS, C stack params and passed struct *s are copied
> and extended/truncated WOW64 before the 64 bit syscall, it will add a
> lil overhead probably). My time improvements in abs time saved
> (minutes) will be the largest of any porter because of these 2
> negative factors.

I'm building on fairly modern, if pedestrian hardware - first generation Core i7, 12GB RAM (which was mostly free), SATA spinning rust drive.

I was building 64-bit binaries on a 64-bit OS.

I have another more idle machine (also 64-bit) which I'll probably use for further testing, but that has a much older CPU (Athon 5200+).[1]

> Random thoughts on the code, both S_check_type_and_open and
> S_doopen_pm do SvPV on their SV.In 1 place in pp_require (doopen_pm's
> caller), SvPVX is done just before doopen_pm. Multiple magic gets
> issue. I know with no .pmc, 1 sub replaces the other. The whole
> sv_newmortal and SvSetSV_nosteal is confusing. Why not just cat onto
> incoming SV the "c", then SvCUR it off? "if
> (PerlLIO_stat(SvPV_nolen_const(pmcsv)" that can become SvPVX since
> sv_catpvn guarentees a PV. In .pmc mode, if there is a .pmc, 2 stats
> are done on it.

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.

In most cases there isn't a .pmc, so the second stat isn't done.

> -------------------------
> if (!IS_SAFE_PATHNAME(p, len, "require"))
>     return NULL;
> -------------------------
> This is done twice on every path between the 2 funcs. I'm not touching
> the mess that is called pp_require.

I considered the performance impact of the duplicate check for this when I added it, but I thought (and still think) that a memchr() against what should be a short string is going to be insignificant against any I/O we do.

Tony

[1] that said, the modern machine has a "windows performance index" of 5.9 while the newer is 5.5. the (more) modern machine is let down by the spinning rust.

---
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