Optimization is done at compile time, and compile time is seen as run time, so little optimization is done. Shorter variable names and hash keys are faster. If you throw away warnings you can double speed with
instead ofif (defined(my $foo = exists $lookup{$bar})) { .... }
In looping through nested data structures you gain speed by pulling out substructures once rather than doing nested lookups. Bonus: this may be clearer.if (exists $lookup{$bar}) { my $foo = $lookup{$bar}; ... }
You can travel synchronized data structures in parallel rather than traversing one and doing hash lookups to find the other.for my $foo (sort keys %some_hash) { my $by_foo = $some_hash{$foo}; for my $bar (sort keys %$by_foo) { my $by_bar = $by_foo->{$bar}; for my $baz (sort keys %$by_bar) { ... } } }
Good news! Using strict encourages fast lexicals.
Yes, I have needed to know this. A report took 3 hours per period, and needed to take less to finish the total job each night. There is no point in running more CPU-bound processes than one has CPUs. Moore did not arrive in time. So the code ran a half-dozen times faster with limited damage done. I did not rewrite in C.
In reply to Re: Structure is more important than speed
by Anonymous Monk
in thread Which way is faster?
by dws
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |