develooper Front page | perl.perl5.porters | Postings from September 2016

Re: [perl #127885] [patches] enhance bench.pl to test same perlunder different options/args

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
September 27, 2016 15:01
Subject:
Re: [perl #127885] [patches] enhance bench.pl to test same perlunder different options/args
Message ID:
20160927150134.GA31196@iabyn.com
On Tue, Apr 12, 2016 at 09:35:31AM -0700, Jim Cromie wrote:
> Porting/bench.pl has 2 interrelated shortcomings:
> 
> 1- it stores cachegrind results using {$testname}{$perlname}.
>    This means that if the same $perlname is used 2x, the 2nd results
>    overwrite the 1st.
> 
> 2- it cannot pass different options/args to each Perl-Under-Test.
> 
> This patchset corrects those problems, allowing to test the same perl
> under different runtime conditions, as caused by the use of different
> -M<foo> etc options.  It was motivated by my desire to test the
> runtime cost of using -DPERL_TRACE_OPS.
> 
> example 0:
> 
>    $] perl Porting/bench.pl --jobs=2 --verbose \
>         --tests=/loop::for::my/ \
>         --perlargs='-MDevel::Peek' \
>         -- \
>         perl5.24.0=+off      -e'"BEGIN{runops_debug(0)}"' \
>         perl5.24.0=+traceops -e'"BEGIN{runops_debug(1)}"'

I'm not entirely happy with this new syntax and implementation.

Firstly, the documentation doesn't make it clear what are perls and
what are perl args, and to which perl they apply. Is it the intention
that all non-perls following a perl (up to but not including the next
perl) are args of the previous perl? i.e.

    perlA -perlA_arg1 -perlA_arg2    perlB -perlB_arg1 -perlB_arg2

Secondly it introduces a bug whereby a misspelled perl executable
name is now just silently ignored: this

    $ Porting/bench.pl nosuchperl perl5240

quite happily benchmarks just perl5240 with no warnings.

Third, the determination of what is a perl executable and what is an arg
seems a bit haphazard. It seems to be: if it starts with a dash, assume
its an arg, else try and execute it, and if it doesn't execute ok, assume
its an arg? I don't like this at all. I'd much prefer it to be
deterministic based on the command line's syntax, although I'm not sure
what syntax. Perhaps args to perl should be part of the same arg as the
executable name, e.g.

    Porting/bench.pl  \
        'perlA+foo -perlA_arg1 -perlA_arg2' \
        'perlB+bar -perlB_arg1 -perlB_arg2'

although I guess that could run afoul of executable pathnames with spaces
in them.


-- 
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.

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