develooper Front page | perl.perl5.porters | Postings from April 2013

Re: [PATCH] On eliminating external tools from the release process

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
April 4, 2013 08:46
Subject:
Re: [PATCH] On eliminating external tools from the release process
Message ID:
20130404084635.GC3729@plum.flirble.org
On Thu, Apr 04, 2013 at 04:09:47AM -0400, bulk 88 wrote:

> Is ExtUtils::Command a suitable replacement for natively calling the shell, 
> performance wise?  I looked at ExtUtils::Command's cp/copy, and from a 

In the general case, no. Definitely not.

But this case is more concerned with portability, maintainability and
reliability than speed. There are plenty of other steps in the release
process which are slower than this.

> On other OSes, prefetching or hinting to the IO scheduler that we are 
> doing sequential reading will serialize and buffer instead of interleave the 
> reads. On others OSes, zero copy DMA to DMA copying is done with
>  kernel help. A for loop through stdio does none of that.

Sure, but in this case, the scripts will immediately block awaiting the
output, on a local machine which is only being used interactively for this
task, so disk IO speed is what's going to matter, not how to reduce CPU
use.

Ultimately, for the release process, we care about elapsed operator time,
reliability, and portability. The resources used to get a release don't
are secondary, as long as they aren't so excessive as to impact on the
primary concerns.

Nicholas Clark

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