And in the future, use Benchmark.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Here's how to check for yourself.

$ perl -MBenchmark=cmpthese -e'my ($foo, $bar); cmpthese(10000000,{ in
+terp => sub{ $foo = qq(gabbit$/)}, concat => sub { $bar = q(gabbit).$
+/}});'
Benchmark: timing 10000000 iterations of concat, interp...
    concat:  6 wallclock secs ( 4.36 usr +  0.00 sys =  4.36 CPU) @ 22
+93577.98/s (n=10000000)
    interp:  6 wallclock secs ( 4.60 usr + -0.01 sys =  4.59 CPU) @ 21
+78649.24/s (n=10000000)
            Rate interp concat
interp 2178649/s     --    -5%
concat 2293578/s     5%     --
$
[download]

Not very significant, particularly since piecing together strings is usually preparation for I/O, a much slower proposition.

Update: A second run, careful to leave other processes idle, produced zero difference. That should be expected.

After Compline,
Zaxo

Japhy is correct. To add on. Don't plan your design around speed unless you are doing some rather heavy stuff. Most of the time your scripts are to simply automate and spending time worring about shaving off a few ticks here and there really doesn't get you much. Especially when you consider that perl is mainly interpreted.

I used to think the same way till I think it was Abigail-II who gave me a smack upside my head and told me not to waste my time. ;-)

Also, agree with the "use benchmark" suggestion!

Stas Bekman and the mod_perl folks have looked into this before. You'll find a more general answer there.

Fellow monks, don't kill me, but I'm quite disappointed with your, let's say, 'evading' answers. While I do agree that for the most time speed considerations at this scope are irrelevant, there are situations (like a mod_perl CGI under rapid fire) where you need every bit of speed you can get. Also noone considered that the length of strings would probably have (quite some) impact on what's faster.

It might be but a loop or subroutine that's part of a (much) larger project, so "don't use perl if you need speed" is quite an ignorant advice. antichef asked us what's faster in Perl, he didn't ask whether Perl was fastest in the first place...

So long,
Flexx

there are situations (like a mod_perl CGI under rapid fire) where you need every bit of speed you can get

The point of upbraiding this monk for his question is that the energy being spent here would be better spent somewhere else. Nearly anywhere else. Asking "which way of doing almost nothing is faster, and maintainability be damned" is a bad attitude and deserves criticism. The method of concatenation will not be the performance bottleneck in any mod_perl script that does anything of significance. Stas was criticized by several people on the list for doing this benchmark, since it only serves to fuel this kind of counterproductive behavior. People need to learn how to do it right: build it, profile it, fix the slow parts, repeat.

There are situations (like a mod_perl CGI under rapid fire) where you need every bit of speed you can get.

After profiling you may find that the performance you are looking for cannot be achieved using your setup. More memory, changing the Apache/mod_perl configuration, a faster processor, more processors, or not doing the bottleneck in Perl (if that's where the bottleneck is) are some of the ways to help you get there.

It might be but a loop or subroutine that's part of a (much) larger project, so "don't use perl if you need speed" is quite an ignorant advice.

Just to make sure: that advice wasn't given.

antichef asked us what's faster in Perl, he didn't ask whether Perl was fastest in the first place...

Assuming he has a performance problem (and not just some theoretical curiosity), maybe he should have. Besides, one form could be rewritten to the other by the optimizer in another Perl version, so what's the point?

— Arien

OK - thanks everyone. Here's why I asked: I wrote and run a site - spamgourmet.com, which is a disposable email address service. I wrote the code and most of the supporting website (all perl) in a couple of weekends. The service now has many thousands of users and processes a great deal of mail every day.

The site has been up for almost two years, during which it has cost me $10 per month. I'm still nowhere close to exceeding the limits placed on my account by my hosting company (he.net - gushing endorsement goes here), and I look forward to keeping it that way. I've also sworn to myself and anyone else who'll listen that the service will always be free - that is, not a source of revenue for anybody. (I suppose I plan to simply stop accepting new users when I hit the ceiling, and then encourage others to take up the cause for new users.) Sales of t-shirts, coffee mugs, etc. during this period have netted $17.01 - not enough for cafepress.com to dislodge a check. I've also received a $10 donation. I couldn't care less. To justify this position to (the many) naysayers in my day-to-day life, I can truthfully say that I spend about as much time and money on the service as going to the movies once a month.

The codebase is small - I've open-sourced it, but I'm not aware of anyone using or extending the code, so my focus is more on keeping the users happy, and keeping the service cheap - so, yes, I'm counting bits. Nevertheless, my aim to maintain balance in these things discourages me from using the scientific method too liberally...

So I came here seeking wisdom. I've been told that string concatenation is a real killer in java. I suspected the same was not true in Perl, but I thought I'd ask here, and my suspicion has been abundantly confirmed. Thanks again.

Hi Arien,

It might be but a loop or subroutine that's part of a (much) larger project, so "don't use perl if you need speed" is quite an ignorant advice.

Just to make sure: that advice wasn't given.

No hard feelings! Somehow I read it that way, but I understand that you didn't mean it that way. My bad.

Look, I gave a pointer to more information on the question being asked. antichef didn't state what's behind his question, so any assumtion on that is just that -- an assumtion. The only thing he has stated was that he did not worry about readability but for speed only, and he got several "don't/bad boy/shame on you" answers. I gave him a pointer to information he was asking for -- so what did I do wrong?

I didn't mean to object on any of the advice given, on the contrary, I agreed in principle.

Besides, one form could be rewritten to the other by the optimizer in another Perl version, so what's the point?

Fine. But what's the point in your objection? Right now, one way might indeed be faster than the other, and brother antichef was courious. I don't know what's wrong with that. Those who know me, know that I am on a crusade for good style and ethics myself, but it's still ok to be courious!

So long
Flexx

What he said, plus...

potentially might be faster than either interpolation or concatenation (which are likely equivalent) but you'd need to use Benchmark to confirm.

I'm not worried about readability, just speed.

If you're so worried about speed that this matters you probably shouldn't be doing this in Perl.

— Arien

in the end it's the same and it's only important to worry about interpolation wehnever you don't need it and should get rid of double quotes. But (imho) it's Premature optimization to care about this issue too much. It saves you 4 keystrokes to use double qoutes here and it's still readable, so use them.

I've just benchmarked $y = 'a '.$x.' b' and $y = "a $x b": with perl 5.6.1 the operator method was (a bit) faster, with 5.8.0 the doublequotes were faster. It is not usefull to worry anyways.