[PATCH] speed up miniperl @INC searching, buildcustomize #13566
Comments
From @bulk88Created by @bulk88See attached patch. Each dir being searched that fails on Win32 results regular build C:\p519\src\win32>perl -MBenchmark -e" timethis(1, 'system(\'nmake\')')" C:\p519\srcnew\win32>perl -MBenchmark -e" timethis(1, 'system(\'nmake\')')" (1656 - 1137) / 60 = 8.65 mins (the following number is a flaky statistic) I've attached a procmon log of miniperl uselessly searching a large num I left the original comment in place for historical reasons. The comment Perl Info |
From @bulk880001-speed-up-miniperl-INC-searching-buildcustomize.patchFrom 8af300d3dcbc3e6955a9f2b79fa73cbb323d6c1d Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Thu, 30 Jan 2014 02:53:09 -0500
Subject: [PATCH] speed up miniperl @INC searching, buildcustomize
most modules are pre-installed in /lib. The buildcustomize modules are
more rarely used than warnings and strict for example. Previously /lib
was the last dir searched with ~1.5 dozen dirs uselessly searched first.
This commit reduced my build time by ~8-9 mins.
---
write_buildcustomize.pl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index 64bf4ce..5309988 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -48,13 +48,18 @@ push @toolchain, 'ext/VMS-Filespec/lib' if $^O eq 'VMS';
unshift @INC, @toolchain;
require File::Spec::Functions;
+# former comment
+#
# lib must be last, as the toolchain modules write themselves into it
# as they build, and it's important that @INC order ensures that the partially
# written files are always masked by the complete versions.
my $inc = join ",\n ",
map { "q\0$_\0" }
- (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib');
+# putting lib first shaves a couple minutes off the build time since the most
+# common modules like warnings and strict are in lib, and as extensions are
+# built the chances of the module being found in lib increases
+ (map {File::Spec::Functions::rel2abs($_)} 'lib', @toolchain);
open my $fh, '>', $file
or die "Can't open $file: $!";
--
1.7.9.msysgit.0
|
From @bulk88On Thu Jan 30 00:01:05 2014, bulk88 wrote:
This was rejected from the P5P ML due to attachment size (250KB limit IIRC). Bumping. -- |
From @iabynOn Thu, Jan 30, 2014 at 12:13:16AM -0800, bulk88 via RT wrote:
[snip; this cuts the 'make' time by: ]
[snip]
For the convenience of others, here is the original patch: Inline Patchdiff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index 64bf4ce..5309988 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -48,13 +48,18 @@ push @toolchain, 'ext/VMS-Filespec/lib' if $^O eq 'VMS';
unshift @INC, @toolchain;
require File::Spec::Functions;
+# former comment
+#
# lib must be last, as the toolchain modules write themselves into it
# as they build, and it's important that @INC order ensures that the partially
# written files are always masked by the complete versions.
my $inc = join ",\n ",
map { "q\0$_\0" }
- (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib');
+# putting lib first shaves a couple minutes off the build time since the most
+# common modules like warnings and strict are in lib, and as extensions are
+# built the chances of the module being found in lib increases
+ (map {File::Spec::Functions::rel2abs($_)} 'lib', @toolchain);
So this doesn't seem safe to me. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Thu, Jan 30, 2014 at 11:25:28AM +0000, Dave Mitchell wrote:
Thanks for ensuring that the patch gets to the list. No, specifically it's completely unsafe for a parallel make. You end up with race conditions where the build fails because one process Which is exactly what the comment in the file tries to explain. However, as Win32 doesn't have parallel makes *yet*, and this seems to be a Nicholas Clark |
From @iabynOn Thu, Jan 30, 2014 at 12:13:16AM -0800, bulk88 via RT wrote:
That does sound extraordinarily slow. On my (admittedly fast) Linux laptop, my @path = ( my $i = 0; Perhaps this implies that's there's something sub-optimal in the way perl -- |
From @bulk88On Thu Jan 30 05:30:31 2014, davem wrote:
Go to the RT ticket through web interface, and look at the bad_inc_procmon.txt attachment, it contains strace like data with wall time on the very left. The calls are sniffed by a filter driver that gets first dibs on all I/O packets (since NT Kernel uses a packetized (or transactional) async I/O model) coming from user mode. A failed @INC test, per dir looks like this after hand trimming of the right side of each line (look at the raw data if you want to see a dump of the args to the syscalls). QueryDirectory is related to enumerating a dir. It requires a dir handle, hence the CreateFile on C:\p519\src\cpan\Test-Harness. "QueryOpen" I'm not sure what C function generates it, or if its called internally by the FS driver, but it fetches this struct http://msdn.microsoft.com/en-us/library/windows/hardware/ff545822%28v=vs.85%29.aspx (from later research it is GetFileAttributesA) 9:08:36.3922806 PM miniperl.exe 1208 CreateFile C:\p519\src\cpan\Test-Harness\DynaLoader.pmc NAME NOT FOUND By setting a BP at the enter kernel mode func, and doing "miniperl -Ilib -e "system('pause'); require FooLoader;"" I'll try to figure out what the syscall were. First one from win32_stat path 0x00a0b660 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pmc" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0b660 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pmc" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0b660 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pmc" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0b660 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pmc" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0b660 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pmc" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 *************************now switch to checking .pm, not .pmc anymore**************************************************** + path 0x00a0a388 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pm" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0a388 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pm" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0a388 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pm" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0a388 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pm" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 + path 0x00a0a388 "C:\perl519\src\cpan\AutoLoader\lib/FooLoader.pm" const char * ntdll.dll!_KiFastSystemCall@0() + 0x2 *****************now on a different dir************************************************* ntdll.dll!_KiFastSystemCall@0() + 0x2 and the loop continues. Note that by calling all the "SomethingFileMoreSomethingA" function calls, each A call does a ASCII to UTF16 conversion. There goes a lil bit of CPU. Maybe win32_stat should do a utf16 conversion and use only kernel32W() and wclib() calls afterwards which dont convert. On Thu Jan 30 03:50:16 2014, nicholas wrote:
make_ext has no provisions for parallel building. No select(), no open3. Can you explain?
What would that process be? -- |
From @iabynOn Thu, Jan 30, 2014 at 11:49:41AM -0800, bulk88 via RT wrote:
Well, what's not clear to me is whether it's the windows system calls that Other than that, I'm really in a position to contribute further to to this
On UNIX, it is normal to run make with -j N, which will do a parallel -- |
From @bulk88According to TonyC, "[23:18] <@TonyC> bulk88: WRT #121119 - I wonder if setting ${^WIN32_SLOPPY_STAT} in buildcustomize.pl would make a noticable difference". Note to self to investigate. |
From [Unknown Contact. See original ticket]According to TonyC, "[23:18] <@TonyC> bulk88: WRT #121119 - I wonder if setting ${^WIN32_SLOPPY_STAT} in buildcustomize.pl would make a noticable difference". Note to self to investigate. |
From @HugmeirOn Thu, Jan 30, 2014 at 12:49 PM, Nicholas Clark <nick@ccl4.org> wrote:
Well, on a technicality, it does: http://perl5.git.perl.org/perl.git/shortlog/refs/heads/hugmeir/cross-compile-win32 Although parallel make on that branch isn't quite functional yet either, I'll be the first to admit that the branch is of dubious value, but if it's |
From @HugmeirOn Mon, Feb 3, 2014 at 5:54 AM, Brian Fraser <fraserbn@gmail.com> wrote:
Actually, on further thought, making the change only take effect for $^O eq |
From @tonycozOn Fri Jan 31 03:31:05 2014, davem wrote:
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.)
I'm not sure why perl builds on Win32 are so slow - I get very fast builds in a VM on the same hardware (eg. a nmake on Win32 took 712 seconds, a Configure + non-parallel make on an Ubuntu VM took 335 seconds).
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. Tony |
From @nwc10On Sun, Feb 02, 2014 at 09:30:49PM -0800, Tony Cook via RT wrote:
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 I'm not sure what the cut off should be - looks like the require code in
Yes, the extension build approach is quite different on *nix from Win32 and So on *nix, the (generated) Makefile contains a target for each extension to
I was going to suggest this. IIRC on the Win32 build there's a complete set (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 Nicholas Clark |
From perl5-porters@perl.orgNicholas Clark wrote:
perlfunc I think.
PL_laststatval and PL_defgv-as-handle seem to be used only in pp func- |
From @tonycozOn Mon Feb 03 01:41:14 2014, nicholas wrote:
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. |
From @bulk88On Mon Feb 03 19:02:17 2014, tonyc wrote:
Since this ticket is heading down different directions. I'll point the following 3 ideas in this ticket so far. 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 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. 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. if (!IS_SAFE_PATHNAME(p, len, "require")) This is done twice on every path between the 2 funcs. I'm not touching the mess that is called pp_require. |
From @demerphqOn 4 February 2014 15:34, bulk88 via RT <perlbug-followup@perl.org> wrote:
Is there any chance it could also be that you have a virus scanner I seem to recall that when I worked under windows the security types Just a thought. Yves |
From @bulk88On Mon Feb 03 23:59:37 2014, demerphq wrote:
It is called TortoiseGit but it isn't active (no TGitCache.exe process running) ATM. Checked again right now during a make clean, 12-18 ms per @INC dir. No TGitCache process. I also tried a non-git bleed build dir, no change in ms per @INC dir. Its still in the 10-20 ms range per dir. -- |
From @druud62On 2014-02-03 10:40, Nicholas Clark wrote:
Partly 'perldoc stat', mostly 'perldoc -f -X'.
See also how 'lstat' plays a role, and how -B resets it, etc. -- |
From @tonycozOn Mon Feb 03 23:34:31 2014, bulk88 wrote:
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 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]
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.
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. |
From @bulk88TLDR, 3 optimizations combined gave me a 1-(839/1582)=46% decrease in build time using the faster baseline of the 2 (if I use the slower baseline, the improvement is even higher). I used a git cleaned WD for each run. Each run is a make all. I did some benchmarking of different optimizations proposed on my "slow" machine. Since I need to put it back into normal duty and each make is very long, I could only do 1 run of each permutation (in 2 cases I thought they were PMC_DISABLE runs, but I later checked the git afterwards and it turned out PMC_DISABLE was on a another blead WD). Notice that the numbers do not add up when you compare each optimization individually, to multi optimization runs, and baseline. OS caching might be playing a role here that /lib first gives the most improvement alone. A WAG says that Windows kernel keeps last used by the process or any process directory open until another directory is touched by a syscall. So after the first syscall to touch that dir, all following stats, dir entry enumerations and attempted opens on that directory do not touch the FS driver or disk driver. When perl/a process touches another dir the last used directory structure is tossed and the fs and disk drivers are called. Note there might be multiple caches at work in Windows kernel/driver stacks, and IDK where they are and how they specifically act. As I said, I can't afford to do more runs to get an average. Regarding strange numbers, 1582 (best baseline)-1047(worst first /lib+sloppy stat) = 535 seconds, but 1157(DISABLE_PMC alone)-839(first /lib+sloppy stat+DISABLE_PMC) = 318 seconds. 1-(318/535) = 40% less gain. baseline, no optimizations Extracting find2perl (with variable substitutions) link -subsystem:console -out:..\x2p\a2p.exe @C:\DOCUME /lib optimization and sloppy stat link -subsystem:console -out:..\x2p\a2p.exe @C:\DOCUME C:\p519\srcnew\win32> no /lib optimization, sloppy stat only if exist ..\x2p\a2p.exe.manifest mt -nologo -manifest ..\x2p\a2p.exe.man /lib optimization only, no sloppy stat C:\p519\srcnew\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils::Comm no /lib optimization only, no sloppy stat, DISABLE_PMC only link -subsystem:console -out:..\x2p\a2p.exe @C:\DOCUME /lib optimization only, sloppy stat, DISABLE_PMC (all 3 on) Linking s2p to psed. patches used for testing win32/win32.h | 1 + Inline Patchdiff --git a/win32/win32.h b/win32/win32.h
index 3d1655a..f5f0187 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -20,6 +20,7 @@
* level in full perl
*/
# define WIN32_NO_SOCKETS
+# define PERL_DISABLE_PMC
#endif
#ifdef WIN32_NO_SOCKETS
----------------------------------------------------------------------------------------
write_buildcustomize.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index 64bf4ce..181a00b 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -54,7 +54,7 @@ require File::Spec::Functions;
my $inc = join ",\n ",
map { "q\0$_\0" }
- (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib');
+ (map {File::Spec::Functions::rel2abs($_)} 'lib', @toolchain);
open my $fh, '>', $file
or die "Can't open $file: $!";
@@ -74,6 +74,8 @@ print $fh <<"EOT" or $error = "Can't print to $file: $!";
# We are miniperl, building extensions
# Replace the first entry of \@INC ("lib") with the list of
# directories we need.
+
+\${^WIN32_SLOPPY_STAT} = 1;
splice(\@INC, 0, 1, $inc);
\$^O = '$osname';
EOT
-- bulk88 ~ bulk88 at hotmail.com |
From @nwc10On Tue, Feb 04, 2014 at 02:35:23PM -0800, Tony Cook via RT wrote:
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)
These seem reasonable, but I don't even know how to do the first, so don't On the subject of testing (that I can't) as George's smoker is unhappy again,
The other thought that I had is that the whole investigation with require Because the internals were originate on Unix they assume that all file That's clearly not the case on Win32, where emulating parts of the data I think it would be useful if someone would audit all the internal uses of This feels like it might make a small general speedup for Win32. Nicholas Clark |
From @demerphqOn 28 February 2014 16:47, Nicholas Clark <nick@ccl4.org> wrote:
${^WIN32_SLOPPY_STAT}=1 if $O eq WINDOWS_O; Yves |
From @steve-m-hayOn 28 February 2014 15:47, Nicholas Clark <nick@ccl4.org> wrote:
Yes, that builds and tests ok for me. And the build is visibly quicker |
From @nwc10On Fri, Feb 28, 2014 at 06:05:18PM +0000, Steve Hay wrote:
Cool. Thanks for testing. Builds OK on VMS too. I have no idea if it was faster as I was out. I'll merge it tomorrow when I'm competent again. Nicholas Clark |
From @craigberryOn Fri, Feb 28, 2014 at 5:29 PM, Nicholas Clark <nick@ccl4.org> wrote:
There is a smoke running now that should report its time and can be |
From @nwc10On Fri, Feb 28, 2014 at 05:36:07PM -0600, Craig A. Berry wrote:
Thanks. On HP's system I got these test failures: Failed 25 tests out of 2164, 98.84% okay. which I think are 2 more than last time I noted the results (August 2013) (re/*, run/*, Devel::Peek failures are new(ish). Previous autodie failure is Nicholas Clark |
From @bulk88On Sun Feb 09 18:18:03 2014, bulk88 wrote:
To get this ticket moving. So I will make a patch with all 3 optimizations above, and all 3 optimizations are done only on Win32? With all the discussion above, AFAIK the consensus is none of the 3 optimizations can be done on anything but Win32. Any final objections to the proposal in this post that would prevent the future patch from being applied? -- |
From @bulk88On Fri Feb 28 18:53:40 2014, bulk88 wrote:
Since I had time. I made the patch. Passed a harness run for me (me=Win32 platform only). -- |
From @bulk880001-perl-121119-speed-up-miniperl-require-on-Win32.patchFrom 4521b236a01d70c7acc6c1e8bb70a114081ad59c Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Sat, 1 Mar 2014 06:20:16 -0500
Subject: [PATCH] [perl #121119] speed up miniperl require on Win32
These 3 optimizations reduce the number of, usually failing, I/O calls
for each "require" for miniperl only. None are appropriate except for
Win32. See #121119 for details.
---
win32/win32.h | 3 +++
write_buildcustomize.pl | 6 +++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/win32/win32.h b/win32/win32.h
index 3d1655a..b2cc94d 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -13,6 +13,7 @@
# define _WIN32_WINNT 0x0500 /* needed for CreateHardlink() etc. */
#endif
+/* Win32 only optimizations for faster building */
#ifdef PERL_IS_MINIPERL
/* this macro will remove Winsock only on miniperl, PERL_IMPLICIT_SYS and
* makedef.pl create dependencies that will keep Winsock linked in even with
@@ -20,6 +21,8 @@
* level in full perl
*/
# define WIN32_NO_SOCKETS
+/* less I/O calls during each require */
+# define PERL_DISABLE_PMC
#endif
#ifdef WIN32_NO_SOCKETS
diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index 64bf4ce..cf429a9 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -54,7 +54,10 @@ require File::Spec::Functions;
my $inc = join ",\n ",
map { "q\0$_\0" }
- (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib');
+ (map {File::Spec::Functions::rel2abs($_)} (
+# faster build on the non-parallel Win32 build process
+ $^O eq 'MSWin32' ? ('lib', @toolchain ) : (@toolchain, 'lib')
+ ));
open my $fh, '>', $file
or die "Can't open $file: $!";
@@ -74,6 +77,7 @@ print $fh <<"EOT" or $error = "Can't print to $file: $!";
# We are miniperl, building extensions
# Replace the first entry of \@INC ("lib") with the list of
# directories we need.
+${\($^O eq 'MSWin32' ? '${^WIN32_SLOPPY_STAT} = 1;':'')}
splice(\@INC, 0, 1, $inc);
\$^O = '$osname';
EOT
--
1.8.0.msysgit.0
|
From @bulk88On Sat Mar 01 03:22:06 2014, bulk88 wrote:
Bump. -- |
From zefram@fysh.orgComment copied from the p5p thread on 5.20 blockers: I'd be happier about it if we actually resolved the commented reason for -zefram |
From @tonycozOn Tue, Mar 25, 2014 at 09:06:58AM +0000, Zefram wrote:
While I think rename into place is a good idea, if Win32 does ever get Tony |
From @bulk88On Tue Mar 25 02:07:22 2014, zefram@fysh.org wrote:
related https://rt-archive.perl.org/perl5/Ticket/Display.html?id=82194 ? -- |
From zefram@fysh.orgbulk88 via RT wrote:
Yes, related. -zefram |
From @bulk88Ill add another very slow @INC with miniperl trace. 5.2 seconds to do "C:\p519\srckhw\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils::Command -e chmod -- 755 blib\man3". The actual IO done on C:\p519\srckhw\dist\ExtUtils-ParseXS\blib\man3 took 8 ms. 5.2 seconds-8ms was spent reading (most of the time), compiling, and executing modules. -- |
From @bulk88 |
From @bulk88On Mon Mar 31 17:08:58 2014, bulk88 wrote:
Is anyone going to review and commit this? -- |
From @steve-m-hayThanks, applied as 8ce7a7e. |
|
@steve-m-hay - Status changed from 'open' to 'resolved' |
From @steve-m-hayOn 25 March 2014 09:06, Zefram <zefram@fysh.org> wrote:
Zefram, bulk88's patch is now committed (8ce7a7e). As discussed here: http://www.nntp.perl.org/group/perl.perl5.porters/2014/04/msg214294.html please can you raise a new ticket for the atomic rename idea above if |
Migrated from rt.perl.org#121119 (status was 'resolved')
Searchable as RT121119$
The text was updated successfully, but these errors were encountered: