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

[rihad]

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).

 

[papahuhn]

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_says_BALLS_on_your forehead]

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?

 

[Brian Wakem]

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

 

[Mahesh Asolkar]

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.

 

[it_says_BALLS_on_your forehead]

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.

 

[Michele Dondi]

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

 

[Michele Dondi]

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

 

[Ben Morrow]

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? )

You forget

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

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

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

 

[Mahesh Asolkar]

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.

 

[Mirco Wahab]

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

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.

 

[Michele Dondi]

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

 

[Michele Dondi]

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

Maybe one needs to $++?


Michele

 

[Michele Dondi]

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

 

[Michele Dondi]

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.

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

 

[Ben Morrow]

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 -\|/-\|/-\|/-\|/)

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

 

[Michele Dondi]

Maybe one needs to $++?

I meant $|++; # Sorry


Michele

 

[rihad]

Quoth Michele Dondi <[email protected]>:
He(?) mentioned that he had already discarded this case.

Yes, I'm a "he"

[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.

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 $!)

 

[Helmut Wollmersdorfer]

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

 

[brian d foy]

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