string concatentation vs. interpolation: which one is more optimal?

Discussion in 'Perl Misc' started by rihad, Sep 26, 2007.

  1. rihad

    rihad Guest

    Programming Perl (The Camel Book) states that "String concatenation is
    also implied by the interpolation that happens in double-quoted
    strings."

    print $a . ' is equal to ' . $b . ".\n"; # dot operator
    print "$a is equal to $b.\n"; # interpolation

    Can someone experienced in Perl source code confirm that they are
    identical in terms of raw speed and memory use or not? The second one
    is much cooler, and if so, I'm going to get rid of concatenation
    altogether. (I'm not even considering the list variant separated by
    commas, which is suboptimal).
    rihad, Sep 26, 2007
    #1
    1. Advertising

  2. rihad

    papahuhn Guest

    rihad schrieb:
    > Programming Perl (The Camel Book) states that "String concatenation is
    > also implied by the interpolation that happens in double-quoted
    > strings."
    >
    > print $a . ' is equal to ' . $b . ".\n"; # dot operator
    > print "$a is equal to $b.\n"; # interpolation
    >
    > Can someone experienced in Perl source code confirm that they are
    > identical in terms of raw speed and memory use or not? The second one
    > is much cooler, and if so, I'm going to get rid of concatenation
    > altogether. (I'm not even considering the list variant separated by
    > commas, which is suboptimal).
    >


    time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
    real 0m14.500s
    user 0m14.460s
    sys 0m0.022s

    time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null

    real 0m12.111s
    user 0m12.081s
    sys 0m0.014s
    papahuhn, Sep 26, 2007
    #2
    1. Advertising

  3. On Sep 26, 1:16 pm, papahuhn <> wrote:
    > rihad schrieb:
    >
    > > Programming Perl (The Camel Book) states that "String concatenation is
    > > also implied by the interpolation that happens in double-quoted
    > > strings."

    >
    > > print $a . ' is equal to ' . $b . ".\n"; # dot operator
    > > print "$a is equal to $b.\n"; # interpolation

    >
    > > Can someone experienced in Perl source code confirm that they are
    > > identical in terms of raw speed and memory use or not? The second one
    > > is much cooler, and if so, I'm going to get rid of concatenation
    > > altogether. (I'm not even considering the list variant separated by
    > > commas, which is suboptimal).

    >
    > time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
    > real 0m14.500s
    > user 0m14.460s
    > sys 0m0.022s
    >
    > time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
    >
    > real 0m12.111s
    > user 0m12.081s
    > sys 0m0.014s


    it probably depends on the length of the string as well. i just wanted
    to add the third option of passing print a list:

    bash-2.03$ time perl -e '$x=$y=303; print "$x $y" for 1..16777216' > /
    dev/null

    real 0m17.710s
    user 0m17.590s
    sys 0m0.002s



    bash-2.03$ time perl -e '$x=$y=303; print $x." ".$y for 1..16777216'
    > /dev/null


    real 0m17.115s
    user 0m17.001s
    sys 0m0.053s



    bash-2.03$ time perl -e '$x=$y=303; print $x," ",$y for 1..16777216'
    > /dev/null


    real 1m18.498s
    user 1m18.310s
    sys 0m0.073s

    MUCH slower for some reason...thoughts?
    it_says_BALLS_on_your forehead, Sep 26, 2007
    #3
  4. rihad

    Brian Wakem Guest

    papahuhn wrote:

    > rihad schrieb:
    >> Programming Perl (The Camel Book) states that "String concatenation is
    >> also implied by the interpolation that happens in double-quoted
    >> strings."
    >>
    >> print $a . ' is equal to ' . $b . ".\n"; # dot operator
    >> print "$a is equal to $b.\n"; # interpolation
    >>
    >> Can someone experienced in Perl source code confirm that they are
    >> identical in terms of raw speed and memory use or not? The second one
    >> is much cooler, and if so, I'm going to get rid of concatenation
    >> altogether. (I'm not even considering the list variant separated by
    >> commas, which is suboptimal).
    >>

    >
    > time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
    > real 0m14.500s
    > user 0m14.460s
    > sys 0m0.022s
    >
    > time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
    >
    > real 0m12.111s
    > user 0m12.081s
    > sys 0m0.014s



    I found almost no difference:

    $ time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null

    real 0m9.109s
    user 0m9.095s
    sys 0m0.012s

    $ time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null

    real 0m9.007s
    user 0m8.997s
    sys 0m0.010s



    And as another poster has pointed out, using a list is very slow by
    comparison:

    $ time perl -e '$a=$b=303; print $a," ",$b for 1..39999999' > /dev/null

    real 0m31.457s
    user 0m31.438s
    sys 0m0.018s


    --
    Brian Wakem
    Brian Wakem, Sep 26, 2007
    #4
  5. On Sep 26, 9:42 am, rihad <> wrote:
    > Programming Perl (The Camel Book) states that "String concatenation is
    > also implied by the interpolation that happens in double-quoted
    > strings."
    >
    > print $a . ' is equal to ' . $b . ".\n"; # dot operator
    > print "$a is equal to $b.\n"; # interpolation
    >
    > Can someone experienced in Perl source code confirm that they are
    > identical in terms of raw speed and memory use or not? The second one
    > is much cooler, and if so, I'm going to get rid of concatenation
    > altogether. (I'm not even considering the list variant separated by
    > commas, which is suboptimal).


    >From the benchmark below, it looks like interpolation and

    concatenation come pretty close.

    -------------------
    #!/usr/bin/perl

    use strict;
    use warnings;
    no warnings 'syntax';

    use Benchmark qw 'cmpthese';

    cmpthese 2000000 => {
    'interp' => '$x=$y=303; $z = "$x $y"',
    'concat' => '$x=$y=303; $z = $x . " " . $y',
    'listjn' => '$x=$y=303; $z = $x," ",$y',
    };

    -------------- Results -------------------

    Rate concat interp listjn
    concat 1428571/s -- -1% -56%
    interp 1438849/s 1% -- -56%
    listjn 3278689/s 130% 128% --
    ------------------

    I usually use one of the two that suits the most. When there is a
    really long line involved, I tend to use the concatenation operator so
    that I can break the line into multiple shorter lines. Interpolation
    is fine in short lines.

    HTH,
    Mahesh.
    Mahesh Asolkar, Sep 26, 2007
    #5
  6. On Sep 26, 3:46 pm, Mahesh Asolkar <> wrote:
    > On Sep 26, 9:42 am, rihad <> wrote:
    >
    > > Programming Perl (The Camel Book) states that "String concatenation is
    > > also implied by the interpolation that happens in double-quoted
    > > strings."

    >
    > > print $a . ' is equal to ' . $b . ".\n"; # dot operator
    > > print "$a is equal to $b.\n"; # interpolation

    >
    > > Can someone experienced in Perl source code confirm that they are
    > > identical in terms of raw speed and memory use or not? The second one
    > > is much cooler, and if so, I'm going to get rid of concatenation
    > > altogether. (I'm not even considering the list variant separated by
    > > commas, which is suboptimal).
    > >From the benchmark below, it looks like interpolation and

    >
    > concatenation come pretty close.
    >
    > -------------------
    > #!/usr/bin/perl
    >
    > use strict;
    > use warnings;
    > no warnings 'syntax';
    >
    > use Benchmark qw 'cmpthese';
    >
    > cmpthese 2000000 => {
    > 'interp' => '$x=$y=303; $z = "$x $y"',
    > 'concat' => '$x=$y=303; $z = $x . " " . $y',
    > 'listjn' => '$x=$y=303; $z = $x," ",$y',
    >
    > };
    >
    > -------------- Results -------------------
    >
    > Rate concat interp listjn
    > concat 1428571/s -- -1% -56%
    > interp 1438849/s 1% -- -56%
    > listjn 3278689/s 130% 128% --
    > ------------------
    >


    This is different than the tests the other posters conducted in that
    you are not printing anything, and I don't think your listjn is doing
    what you think it is.
    it_says_BALLS_on_your forehead, Sep 26, 2007
    #6
  7. On Wed, 26 Sep 2007 09:42:11 -0700, rihad <> wrote:

    >Subject: string concatentation vs. interpolation: which one is more optimal?


    Something can't be "more optimal" than something else. Perhaps
    "optimized"?

    >print $a . ' is equal to ' . $b . ".\n"; # dot operator
    >print "$a is equal to $b.\n"; # interpolation


    You forget

    print $a, ' is equal to ', $b, ".\n"; # print() takes a list

    >Can someone experienced in Perl source code confirm that they are
    >identical in terms of raw speed and memory use or not? The second one
    >is much cooler, and if so, I'm going to get rid of concatenation
    >altogether. (I'm not even considering the list variant separated by
    >commas, which is suboptimal).


    Do you *really* care?!? I agree that sometimes it *is* worth to look
    at optimizations, but if you have performance problems, then the
    printing of a short thing is highly likely *not* to be the cause of
    them, and if it is, then you'd better switch to a faster language
    altogether.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 26, 2007
    #7
  8. On Wed, 26 Sep 2007 12:46:32 -0700, Mahesh Asolkar <>
    wrote:

    >cmpthese 2000000 => {
    > 'interp' => '$x=$y=303; $z = "$x $y"',
    > 'concat' => '$x=$y=303; $z = $x . " " . $y',
    > 'listjn' => '$x=$y=303; $z = $x," ",$y',


    The last entry does something completely different altogether, because
    the list is evaluated in scalar context, whereas in print() it's in
    list context.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 26, 2007
    #8
  9. rihad

    Ben Morrow Guest

    Quoth Michele Dondi <>:
    > On Wed, 26 Sep 2007 09:42:11 -0700, rihad <> wrote:
    >
    > >Subject: string concatentation vs. interpolation: which one is more optimal?

    >
    > Something can't be "more optimal" than something else. Perhaps
    > "optimized"?


    Yes it can. 'more optimal' implies 'better, in an absolute sense',
    whereas 'more optimized' would imply 'has been improved more'. That is,
    if you have A which executes 10 times a second and B which executes 20
    times, and you improve this to A executing 15 times and B executing 21
    times, then A is 'more optimized' than B even though B is still 'more
    optimal' than A. (Did that make any sense? :) )

    > >print $a . ' is equal to ' . $b . ".\n"; # dot operator
    > >print "$a is equal to $b.\n"; # interpolation

    >
    > You forget
    >
    > print $a, ' is equal to ', $b, ".\n"; # print() takes a list


    He(?) mentioned that he had already discarded this case.

    > >Can someone experienced in Perl source code confirm that they are
    > >identical in terms of raw speed and memory use or not? The second one
    > >is much cooler, and if so, I'm going to get rid of concatenation
    > >altogether. (I'm not even considering the list variant separated by
    > >commas, which is suboptimal).

    >
    > Do you *really* care?!? I agree that sometimes it *is* worth to look
    > at optimizations, but if you have performance problems, then the
    > printing of a short thing is highly likely *not* to be the cause of
    > them, and if it is, then you'd better switch to a faster language
    > altogether.


    While I couldn't agree more, in the interests of answering the question
    asked:

    ~% perl -MO=Concise -e'$a . " foo " . $b'
    8 <@> leave[1 ref] vKP/REFC ->(end)
    1 <0> enter ->2
    2 <;> nextstate(main 1 -e:1) v ->3
    7 <2> concat[t2] vKS/2 ->8
    5 <2> concat[t1] sK/2 ->6
    - <1> ex-rv2sv sK/1 ->4
    3 <$> gvsv(*a) s ->4
    4 <$> const(PV " foo ") s ->5
    - <1> ex-rv2sv sK/1 ->7
    6 <$> gvsv(*b) s ->7
    -e syntax OK
    ~% perl -MO=Concise -e'"$a foo $b"'
    8 <@> leave[1 ref] vKP/REFC ->(end)
    1 <0> enter ->2
    2 <;> nextstate(main 1 -e:1) v ->3
    - <1> ex-stringify vK/1 ->8
    - <0> ex-pushmark s ->3
    7 <2> concat[t2] sKS/2 ->8
    5 <2> concat[t1] sK/2 ->6
    - <1> ex-rv2sv sK/1 ->4
    3 <$> gvsv(*a) s ->4
    4 <$> const(PV " foo ") s ->5
    - <1> ex-rv2sv sK/1 ->7
    6 <$> gvsv(*b) s ->7
    -e syntax OK

    The ex-foo ops are those that have been optimized away, so they compile
    to exactly the same optree, so have exactly the same performance. Any
    differences found elsewhere in the thread are errors in benchmarking.

    Ben
    Ben Morrow, Sep 26, 2007
    #9
  10. On Sep 26, 1:41 pm, Michele Dondi <> wrote:
    > On Wed, 26 Sep 2007 12:46:32 -0700, Mahesh Asolkar <>
    > wrote:
    >
    > >cmpthese 2000000 => {
    > > 'interp' => '$x=$y=303; $z = "$x $y"',
    > > 'concat' => '$x=$y=303; $z = $x . " " . $y',
    > > 'listjn' => '$x=$y=303; $z = $x," ",$y',

    >
    > The last entry does something completely different altogether, because
    > the list is evaluated in scalar context, whereas in print() it's in
    > list context.
    >


    Michele and it_says_BALLS_on_your forehead, yes listjn is really quite
    different from what the OP wanted. I was trying to isolate performance
    of concatenation and interpolation operations from the IO overhead of
    print - if at all. I did not pay attention on the side effect on
    listjn. My apologies.

    /Mahesh.
    Mahesh Asolkar, Sep 26, 2007
    #10
  11. rihad

    Mirco Wahab Guest

    it_says_BALLS_on_your forehead wrote:
    > bash-2.03$ time perl -e '$x=$y=303; print $x," ",$y for 1..16777216'
    >> /dev/null

    >
    > real 1m18.498s
    > user 1m18.310s
    > sys 0m0.073s
    >
    > MUCH slower for some reason...thoughts?


    Interesting.

    Seems to hang on perl stdout, consider ...
    (taken from the other thread):
    =>

    use Benchmark qw 'cmpthese';
    our $fh;
    open $fh, '>', '/dev/null' or die $!;
    cmpthese 2000000 => {
    #'spinterp' => '$x=$y=303; $z = sprintf "%s", "$x $y"',
    #'spconcat' => '$x=$y=303; $z = sprintf "%s", $x . " " . $y',
    #'spLISTjn' => '$x=$y=303; $z = sprintf "%s", $x, " ", $y',
    #'spJOINjn' => '$x=$y=303; $z = sprintf "%s", join("", $x," ",$y)',

    'printerp' => '$x=$y=303; $z = print $fh "$x $y"',
    'prconcat' => '$x=$y=303; $z = print $fh $x . " " . $y',
    'prLISTjn' => '$x=$y=303; $z = print $fh $x," ",$y' ,
    'prJOINjn' => '$x=$y=303; $z = print $fh join("", $x, " ", $y)',
    };
    close $fh;
    <=

    will give (here):

    Rate prJOINjn prconcat printerp prLISTjn
    prJOINjn 1298701/s -- -12% -24% -34%
    prconcat 1481481/s 14% -- -13% -24%
    printerp 1709402/s 32% 15% -- -13%
    prLISTjn 1960784/s 51% 32% 15% --


    "List" seems to be always fastest w/all print
    varieties, except when going through stdio?

    Regards

    M.
    Mirco Wahab, Sep 26, 2007
    #11
  12. On Wed, 26 Sep 2007 19:16:16 +0200, papahuhn <> wrote:

    >time perl -e '$a=$b=303; print "$a $b" for 1..39999999' > /dev/null
    >real 0m14.500s
    >user 0m14.460s
    >sys 0m0.022s
    >
    >time perl -e '$a=$b=303; print $a." ".$b for 1..39999999' > /dev/null
    >
    >real 0m12.111s
    >user 0m12.081s
    >sys 0m0.014s


    I think that using time is simply not reliable enough. Benchmark.pm is
    not perfect either, but could come closer. I adapted another poster's
    script as follows:

    pilsner:~ [22:54:10]$ cat bench.pl
    #!/usr/bin/perl

    use strict;
    use warnings;
    no warnings 'once';

    use Benchmark qw/cmpthese :hireswallclock/;

    open F, '>/dev/null' or die;

    cmpthese -20 => {
    'interp' => '$x=$y=303; print F "$x $y"',
    'concat' => '$x=$y=303; print F $x . " " . $y',
    'listjn' => '$x=$y=303; print F $x," ",$y',
    };

    __END__
    pilsner:~ [22:54:19]$ perl bench.pl
    Rate interp concat listjn
    interp 770456/s -- -0% -2%
    concat 773664/s 0% -- -1%
    listjn 783474/s 2% 1% --


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 26, 2007
    #12
  13. On Wed, 26 Sep 2007 23:59:56 +0200, Mirco Wahab
    <-halle.de> wrote:

    >"List" seems to be always fastest w/all print
    >varieties, except when going through stdio?


    Maybe one needs to $++?


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 26, 2007
    #13
  14. On Wed, 26 Sep 2007 14:28:52 -0700, Mahesh Asolkar <>
    wrote:

    >Michele and it_says_BALLS_on_your forehead, yes listjn is really quite
    >different from what the OP wanted. I was trying to isolate performance
    >of concatenation and interpolation operations from the IO overhead of
    >print - if at all. I did not pay attention on the side effect on
    >listjn. My apologies.


    (No need to apologize, you didn't offend anyone!) But you *can't*, for
    the print() does the actual concatenation we're interested into.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 26, 2007
    #14
  15. On Wed, 26 Sep 2007 22:27:56 +0100, Ben Morrow <>
    wrote:

    >Quoth Michele Dondi <>:
    >> Something can't be "more optimal" than something else. Perhaps
    >> "optimized"?

    >
    >Yes it can. 'more optimal' implies 'better, in an absolute sense',
    >whereas 'more optimized' would imply 'has been improved more'. That is,
    >if you have A which executes 10 times a second and B which executes 20
    >times, and you improve this to A executing 15 times and B executing 21
    >times, then A is 'more optimized' than B even though B is still 'more
    >optimal' than A. (Did that make any sense? :) )


    Well, "optimal" is an adjective of clear latin descent. In Italian it
    maps to "ottimale" which is somewhat a variant (with a slightly
    restricted acceptation) of "ottimo" (best) which in turn is the
    superlative of "buono" (good) and IMHO still has attached the sense of
    a superlative. I don't know if in English it's the same or I'm simply
    biased by Italian grammar, but...

    (/me realizes that he can check dict to be sure -\|/-\|/-\|/-\|/)

    no, it seems it's the same in English:

    : From The Collaborative International Dictionary of English v.0.48 :
    :
    : optimal \op"ti*mal\, a.
    : Best possible; most desirable; optimum; as, the optimal
    : concentration of a drug.
    : [PJC]
    :
    :
    : From WordNet (r) 2.0 :
    :
    : optimal
    : adj : most desirable possible under a restriction expressed or
    : implied; "an optimum return on capital"; "optimal
    : concentration of a drug" [syn: optimum]

    [other two entries snipped, but the concept is the same]

    So to say that something is "more optimal" (than something else) is
    like saying that something is "more best" (than something else). To
    me, it's not correct.

    >> print $a, ' is equal to ', $b, ".\n"; # print() takes a list

    >
    >He(?) mentioned that he had already discarded this case.


    Sorry, didn't notice. Apologies to the OP.

    >> Do you *really* care?!? I agree that sometimes it *is* worth to look
    >> at optimizations, but if you have performance problems, then the
    >> printing of a short thing is highly likely *not* to be the cause of
    >> them, and if it is, then you'd better switch to a faster language
    >> altogether.

    >
    >While I couldn't agree more, in the interests of answering the question
    >asked:
    >
    > ~% perl -MO=Concise -e'$a . " foo " . $b'

    [snip]
    >The ex-foo ops are those that have been optimized away, so they compile
    >to exactly the same optree, so have exactly the same performance. Any
    >differences found elsewhere in the thread are errors in benchmarking.


    Very instructive, thanks!


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 27, 2007
    #15
  16. rihad

    Ben Morrow Guest

    [OT] optimal vs. optimized [was: Re: string concatentation...]

    Quoth Michele Dondi <>:
    > On Wed, 26 Sep 2007 22:27:56 +0100, Ben Morrow <>
    > wrote:
    >
    > >Quoth Michele Dondi <>:
    > >> Something can't be "more optimal" than something else. Perhaps
    > >> "optimized"?

    > >
    > >Yes it can. 'more optimal' implies 'better, in an absolute sense',
    > >whereas 'more optimized' would imply 'has been improved more'. That is,
    > >if you have A which executes 10 times a second and B which executes 20
    > >times, and you improve this to A executing 15 times and B executing 21
    > >times, then A is 'more optimized' than B even though B is still 'more
    > >optimal' than A. (Did that make any sense? :) )

    >
    > Well, "optimal" is an adjective of clear latin descent. In Italian it
    > maps to "ottimale" which is somewhat a variant (with a slightly
    > restricted acceptation) of "ottimo" (best) which in turn is the
    > superlative of "buono" (good) and IMHO still has attached the sense of
    > a superlative. I don't know if in English it's the same or I'm simply
    > biased by Italian grammar, but...
    >
    > (/me realizes that he can check dict to be sure -\|/-\|/-\|/-\|/)

    <snipped>
    >
    > So to say that something is "more optimal" (than something else) is
    > like saying that something is "more best" (than something else). To
    > me, it's not correct.


    You have a good point; however, as is usual in English grammar,
    arguments from ancestry don't always help :). For instance, if 'optimum'
    and derived words are necessarily superlative, then 'optimized' means
    'made best', and A cannot be more optimized than B either. A has either
    been 'made best' or it hasn't.

    I think what has happened is that, in English, 'optimal' and
    'optimized' have acquired something of a sense of 'efficient', which is
    clearly comparative, rather than of 'best' in a more general sense. So
    optimizing a program doesn't necessarily make it better, it simply makes
    it more efficient: other things may be more important than efficiency,
    portability or readability for example. 'Optimum' has not (I would say)
    changed like this, so I find it odd that the dictionaries you quoted say
    it is synonymous with 'optimal': I would entirely agree that 'more
    optimum' is obviously wrong.

    Theory aside, a quick google shows that 'more optimal' is definitely
    acceptable usage; for instance (a random example from the results)

    This is because the claim that A is more optimal or better adapted
    than B with respect to some function does not entail that A is
    optimal or even good with respect to that function.

    http://www.seop.leeds.ac.uk/archives/fall1999/entries/teleology-biology/

    which shows that 'optimal' can have the sense of 'efficient' or
    'effective' rather than simply 'best'.

    [English] not only borrows words from other languages; it has on
    occasion chased other languages down dark alley-ways, clubbed them
    unconscious and rifled their pockets for new vocabulary.
    -- James Nicoll
    :)

    Ben
    Ben Morrow, Sep 27, 2007
    #16
  17. On Thu, 27 Sep 2007 00:35:45 +0200, Michele Dondi
    <> wrote:

    >>"List" seems to be always fastest w/all print
    >>varieties, except when going through stdio?

    >
    >Maybe one needs to $++?


    I meant $|++; # Sorry


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, Sep 27, 2007
    #17
  18. rihad

    rihad Guest

    On Sep 27, 2:27 am, Ben Morrow <> wrote:
    > Quoth Michele Dondi <>:
    > He(?) mentioned that he had already discarded this case.
    >

    Yes, I'm a "he" :)

    > > >Can someone experienced in Perl source code confirm that they are
    > > >identical in terms of raw speed and memory use or not? The second one
    > > >is much cooler, and if so, I'm going to get rid of concatenation
    > > >altogether. (I'm not even considering the list variant separated by
    > > >commas, which is suboptimal).

    >
    >
    >

    [snipped]
    > The ex-foo ops are those that have been optimized away, so they compile
    > to exactly the same optree, so have exactly the same performance. Any
    > differences found elsewhere in the thread are errors in benchmarking.
    >
    > Ben


    Thank you very much, Ben! Thanks everyone else for sparkling up the
    topic too.


    >Quoth Michele Dondi <>:
    >> Something can't be "more optimal" than something else. Perhaps
    >> "optimized"?


    > Well, "optimal" is an adjective of clear latin descent. In Italian it
    > maps to "ottimale" which is somewhat a variant (with a slightly
    > restricted acceptation) of "ottimo" (best) which in turn is the
    > superlative of "buono" (good) and IMHO still has attached the sense of
    > a superlative. I don't know if in English it's the same or I'm simply
    > biased by Italian grammar, but...


    My apologies if "more optimal" happens to not be proper English: I
    simply mapped the Russian " " [boleye optimal'niy] to
    "more optimal" verbatim, which happened to not be too far from the
    truth, as Ben's counterarguments later showed :)

    It's very amusing to learn English and Perl side by side. For example,
    "unless (...)" Perl lingo doesn't ring the bell for non-native (non-
    american?) English speakers too much (at least not for me), so I try
    to avoid it and use "if (not ...)" instead. "California or bust" is
    okay, though (open ... or die $!)
    rihad, Sep 27, 2007
    #18
  19. Re: [OT] optimal vs. optimized

    Ben Morrow wrote:

    > I think what has happened is that, in English, 'optimal' and
    > 'optimized' have acquired something of a sense of 'efficient',


    Both are meaningless.

    I always try to exchange 'optimize' by 'maximize' or 'minimize', e.g.

    - minimize runtime
    - minimize memory usage
    - maximize execution rate
    - maximize readability
    - maximize test coverage

    Helmut Wollmersdorfer
    Helmut Wollmersdorfer, Sep 27, 2007
    #19
  20. rihad

    brian d foy Guest

    In article <>,
    rihad <> wrote:

    > Programming Perl (The Camel Book) states that "String concatenation is
    > also implied by the interpolation that happens in double-quoted
    > strings."


    > Can someone experienced in Perl source code confirm that they are
    > identical in terms of raw speed and memory use or not?


    When you start looking at the speed of things like this and actaully
    caring about the answer, you'll probably find that Perl is not the
    right tool for the job. Perl is really fast, but if this sort of
    operation is too slow for you, then the bigger tasks in Perl, uch as
    using a module, will just kill your performance (relatively).

    Before anyone gets too concerned about small details like this
    (especially when Perl is not constrained to implement them in any way
    and the next release of Perl might do it differently), try profiling
    the application that you are concerned about. You'll find easier and
    slower things to fix and worry about :)
    brian d foy, Sep 27, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Salerno
    Replies:
    16
    Views:
    447
    bruno at modulix
    May 12, 2006
  2. Merciadri Luca
    Replies:
    4
    Views:
    809
  3. Daniel Bergquist

    Concatentation

    Daniel Bergquist, Jul 13, 2004, in forum: Perl Misc
    Replies:
    4
    Views:
    103
    Daniel Bergquist
    Jul 14, 2004
  4. Steven D'Aprano
    Replies:
    0
    Views:
    90
    Steven D'Aprano
    Dec 23, 2013
  5. Replies:
    3
    Views:
    82
    Gary Herron
    Dec 23, 2013
Loading...

Share This Page