On Wed, May 30, 2001 at 12:14:29PM -0400, Uri Guttman wrote:
> >>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
