Front page | perl.perl5.porters |
Postings from February 2014
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