Optimize Perl..

[Matija Papec]

http://www-106.ibm.com/developerworks/library/l-optperl.html?ca=dgr-lnxw06OptPerl

Usually they have good articles but this one isn't nearly there, and I doubt
that author is just making jokes in it?

 

[A. Sinan Unur]

http://www-106.ibm.com/developerworks/library/l-optperl.html?ca=dgr-lnx
w06OptPerl

Usually they have good articles but this one isn't nearly there, and I
doubt that author is just making jokes in it?

It is an odd article. The author starts with non-issues and comes up with
the obvious solutions: "If you are going to concatenate a string a million
times, don't use a loop!"

In any case, even if that is the level of the target audience, I would not
put much stock in this article. How can someone fail to mention the
Benchmark module in an article about optimization?

Sinan.

 

[Uri Guttman]

MP> http://www-106.ibm.com/developerworks/library/l-optperl.html?ca=dgr-lnxw06OptPerl
MP> Usually they have good articles but this one isn't nearly there,
MP> and I doubt that author is just making jokes in it?

here is the feedback i sent him:

so many misconceptions about perl that i can't even start. and
he misses so many ways to optimize perl as well.

no mention of the Benchmark.pm module.

perl bytecode is generally useless and doesn't give much speedup

choosing a better algorithm and/or data structure is the best
way to optimize code in any language. if you think perl 's speed
is the problem then you either chose the wrong language or don't
know how to code perl efficiently. examining bytecode is silly
in this context. it still won't show you which ops are the
bottlenecks.

the speed difference between single and double quoted strings is
negligible. try a benchmark yourself. double quoted strings are
converted to a join of the string parts at compile time so there
is no runtime loss for simple strings.

want more? write to me at (e-mail address removed).

let's see if i get any response.

uri

 

[Matija Papec]

X-Ftn-To: A. Sinan Unur

It is an odd article. The author starts with non-issues and comes up with
the obvious solutions: "If you are going to concatenate a string a million
times, don't use a loop!"

In any case, even if that is the level of the target audience, I would not
put much stock in this article. How can someone fail to mention the
Benchmark module in an article about optimization?

Yes, it would be nice to mention it; at first I was surprised with foreach
being replaced with map in void context, as a superior solution to foreach
loop? Then it shows some sorting example (yes, map is once again being
misused) where it shows caching technique altering primary data and calling
twice keys of the same hash. Then I looked back to the title and tried to
make some connection between them.

 

[Matija Papec]

X-Ftn-To: Uri Guttman

the speed difference between single and double quoted strings is
negligible. try a benchmark yourself. double quoted strings are
converted to a join of the string parts at compile time so there
is no runtime loss for simple strings.

want more? write to me at (e-mail address removed).

let's see if i get any response.

I hope they'll remove the article; the one thing that can happen is that
someone will read it and embrace as coding guidelines.

 

[ctcgag]

http://www-106.ibm.com/developerworks/library/l-optperl.html?ca=dgr-lnxw0
6OptPerl

Usually they have good articles but this one isn't nearly there, and I
doubt that author is just making jokes in it?

I fully expect that, in the next few days, I will be forwarded this article
by someone in senior management, who will demand to know how many of these
"best practises" I implement.

Xho

 

[Matija Papec]

X-Ftn-To: (e-mail address removed)

I fully expect that, in the next few days, I will be forwarded this article
by someone in senior management, who will demand to know how many of these
"best practises" I implement.

Well you don't have much time then; forget all your wrong and sinful
practices, and confess that you'll overcome them.


ps. I hope you're joking, right?