Front page | perl.perl6.internals |
Postings from June 2001
On Wed, May 30, 2001 at 12:14:29PM -0400, Uri Guttman wrote: > >>>>> "NI" == Nick Ing-Simmons <nick@ing-simmons.net> writes: > > NI> The "overhead of op dispatch" is a self-proving issue - if you > NI> have complex ops they are expensive to dispatch. > > but as someone else said, we can design our own ops to be as high level > as we want. lowering the number of op calls is the key. that loop will > be a bottleneck as it is in perl5 unless we optimize it now. > In my experience, perl opcodes have not been the performance bottleneck in perl5. It seems it isn't actually the loop that's the bottleneck in perl5. I profiled a whole bunch of different perl programs, using a lot of different versions of perl5; and the runops loop was very rarely among the top CPU users. Many times, the opcode routines themselves weren't the hot spots. It was the support routines like hash key calculation and lookup, string comparisons, or the regular expression code. Profiling is almost always counter-intuitive, but if I had to guess, I'd say that most of the per-opcode cost in perl5 was due to setup/initialization as each opcode was entered, and that devious/clever data structure design could avoid most of this. Also, opcode dispatch might not be the right tree up which to be barking in seeking performance. -- Ed Mooring (mooring@acm.org)Thread Previous | Thread Next