At 01:09 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>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.
Yeah, a lot of that's definitely a problem, as is the manipulation of the
return stack and some assignment bits. (You can cut the time split takes in
half by having the destination array presized, for example)
>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.
The setup/teardown costs are definitely a heavy expense. We can cut it down
some, hopefully a lot in some cases, but there are limits to what can be
done. If they're treated as a fixed cost (which they more or less are),
then the less often we pay that cost the better.
Unfortunately there's also the problem of having *too* many opcode
functions, at which point you pay a lot of cycles in cache miss times
fetching in Specially Optimized Function #4327. It seems, though, that if
we have the option of doing something in one opcode instead of 10 or 20, it
makes sense to do so as we reduce the constant costs.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
