in reply to Micro optimisations can pay off, and needn't be a maintenance problem

There are two things I'd like to point out about this. The first is that you have found an extremely rare beast: a CPU-bound Perl program! In practical applications of Perl, nearly all programs are limited by IO (database, file, network) rather than CPU. This is why no one would write a 3D rendering tool in Perl except as a learning exercise like this one.

The second is that most of us don't actually object to micro-optimization once you've found that a particular routine is the bottleneck. What I object to is the tendency many people have to say "I haven't done any profiling or measuring of any kind to see what the problem is, but I'm going to change all of this section to use some ugly code because 'map' is 2% faster than 'foreach'", or some such.

The biggest gains always come from changing large things, like removing an unnecessary IO operation or changing your algorithm or data structure, but if you find that a particular sub is a problem then it does make sense to try and fix it. If your object access really is the thing that's killing performance here, you could also try using arrays instead of hashes for the objects. Here's an example with your accessor optimization:

package Things5; use constant CLASS => 0; use constant SELF => 0; use constant VALUE => 1; use constant THING => 0; sub new { my $object = []; $object->[THING] = 0; return bless $object, $_[CLASS]; } sub get_it { return $_[SELF]->[THING]; } sub set_it { return $_[SELF]->[THING] = $_[VALUE]; } 1;
  • Comment on Re: Micro optimisations can pay off, and needn't be a maintenance problem
  • Download Code

Replies are listed 'Best First'.
Re: Re: Micro optimisations can pay off, and needn't be a maintenance problem
by grantm (Parson) on Nov 12, 2002 at 20:26 UTC
    'map' is 2% faster than 'foreach'

    Wow, I never knew that! I'll go and run a search and replace over all my scripts now.

    :-)