At 11:55 AM 8/25/00 -0400, Michael Maraist wrote:
> > You will *not* improve the performance of the inner interpreter
> > loop by having fewer opcodes to switch on. Whether the number is
> > 20 or 200, it's the same thing--*think* aboutit.
>
>Well, not strictly true. Though the raw code will not switch any faster,
>the bloat of the core will hurt you with non-locality, through cache misses,
>or worse memory-paging.
That, as they say, turns out not to be the case, at least not in the
general case. Code you don't call won't eat up any cache space, nor crowd
out some other code. And if you do call it, well, it ought to be in the cache.
Now there are issues--if we have an indirect function table, it makes sense
for the pointers for functions called in succession be close to one another
to get a win from cache prefetching, but reasonable ordering of functions
in the array (if we even have one) takes care of that.
>So long as auto-loading (for legacy functions) makes it transparent, the
>usefulness will not decrease one bit. The only things that are affected are
>the performance (which depends on how old-op-code auto-loading is achieved),
>and what happens when you ship the perl executable without any libraries
>(which I've had to do on occasion).
Performance is king and queen here. Anything that slows performance down
without a big functional win will go.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
