Paolo Molaro <[EMAIL PROTECTED]> wrote:
> On 10/29/04 Leopold Toetsch wrote:
>> Well, we already got a nice method cache, which makes lookup a
>> vtable-like operation, i.e. an array lookup. But that's runtime only
>> (and it needs invalidation still). So actually just the first method
>> lookup is a hash operation.
> And where is it cached and how?
in src/objects.c:1077 ff. It's indexed by some bits of the method's
name address.
> From your description it seems it would look like:
> vtable = $i->vtable;
> code = vtable->method_lookup ("method"); // C function call
> run_code (code);
The method_lookup doesn't have a vtable indirection. And having a direct
array lookup doesn't really scale. So the actual code is a bit more
complicated (and in no way optimized).
> Note that $i may be of different type for each loop iteration.
Sure.
> Even a cached lookup is going to be slower than a simple memory
> dereference. Of course this only matters if the lookup is
> actually a bottleneck of your function call speed.
Function calling is currently being changed. So I don't know yet.
>> > matter in parrot as long as bytecode values are as big as C ints:-)
[ more about op size ]
Well, that isn't an issue currently, AFAIK. More time consuming things
need optimizations first.
> BTW, in the computed goto code, make the array of address labels const:
> it helps reducing the rw working set at least when parrot is built as an
> executable.
Ah, yep. Thanks for the tip.
> lupus
leo
