Re: Perl Performance Tuning
- From: Uri Guttman <uri@xxxxxxxxxxxxxxx>
- Date: Sun, 23 Apr 2006 16:45:37 -0400
"o" == occitan <occitan@xxxxxxxxxxxxx> writes:
o> http://makepp.sourceforge.net/1.50/perl_performance.html
o> This should be required reading for all Perl hackers, including those
o> who write the alas sometimes suboptimal documentation.
there are some odd points in that and plenty of stuff you missed. also
the wording is very bizarre in some places.
@_ is not called the stack. it is @_. calling with &foo just leaves @_
as it is and so it can be used by the callee. but as that is a bug
waiting to happen, i wouldn't use it just for speedups.
as for passing around long strings, using the $_[0] to directly access
them is also a bug waiting to happen. just pass them by reference and
all is well. you get a proper named variable and no extra copying of
string in the arg list.
who in their right mind uses lots of bit flags for booleans in perl? in
c it makes sense for packing reasons but with perl that won't save
storage since SV's all take up overhead way beyond a few bits. maybe you
mistakenly tried that and it was slow but i wouldn't have even ventured
down that path to begin with.
choosing for vs map is more than just speed. it has to do with side
effects or generating a result list. and the size of the input list
matters too.
use undef instead of 0 makes no sense. you seem to be boolean flag crazy
if that matters to you. as such i would redesign the code to not need so
many flags. flags are not perlish, especially flags in conditionals and
loops. and i believe a basic sv can store an integer or undef (a flag)
using the same space. only a hash or array could have undef as an
element and same space and only if it is done a certain way. $foo{bar} =
undef will use the same space as 0 as it will allocate an SV for
that. but @foo{@keys} = () will not allocate sv's and will same some
space but that means boolean tests on it must be done with exists().
the amount of time you spend on such optimizations would be
better spent on better design and code. and i am not even talking better
algorithms. you can implement the same algorithm in many different ways
and with many different speed results.
avoiding hashes is a very foolish thing to say. arrays as objects are
not much faster at all. look at the brutal history of pseudohashes in
perl. they were invented to do exactly what you claim is important and
they never proved to be so much faster. they only caused nasty hard to
fix bugs when they were used outside their very tiny design envelope. i
would wager that it is how you used the hashes that cause your
problems. this goes again to a better design and not avoiding hashes.
there are so many other ways to optimize programs. i would first do a
full design and code review and then see what comes out of that. then
you can run profiling on the programs and focus on speeding up only the
largest cpu hogs and not all those little things you seem to mention. i
would prefer to waste some cpu in order to have better and more
maintainable code. if you really need speed, use xs not perl.
if you a want a proper design and/or code review, let me know.
uri
--
Uri Guttman ------ uri@xxxxxxxxxxxxxxx -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
.
- Follow-Ups:
- Re: Perl Performance Tuning
- From: Peter J. Holzer
- Re: Perl Performance Tuning
- From: Ilya Zakharevich
- Re: Perl Performance Tuning
- From: Marc Dashevsky
- Re: Perl Performance Tuning
- References:
- Perl Performance Tuning
- From: occitan
- Perl Performance Tuning
- Prev by Date: Perl Performance Tuning
- Next by Date: Re: FAQ 4.41 How can I remove duplicate elements from a list or array?
- Previous by thread: Perl Performance Tuning
- Next by thread: Re: Perl Performance Tuning
- Index(es):
Relevant Pages
|
