DMD 0.161 release

[Ben Hinkle]

> I tested speed of various calling methods with
> http://www.xs0.com/d/ifaces.d.html
>
> and here are the results I get:
>
>               Normal:             12165450 / sec
>    Through interface:             11764706 / sec
>    Lookup every time:              9580379 / sec
>     Optimized lookup:             13390466 / sec
>     Static functions:             13224015 / sec
>
> The number is function calls / second.
>
> With a function of any significant complexity, the differences would be 
> even smaller, and even here it's just around 20% in the worst case. And if 
> a simple observation* is implemented in the optimizer, the speed loss in 
> fact becomes speed gain (ok, in reality it would also be implemented for 
> non-interface methods, so the speed would end up the same).
>
> *) if the object reference doesn't change neither can the function pointer

ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
vtable lookup is linear in the total number of interfaces the class 
implements (including the interfaces of super-interfaces) it could be more 
noticeable in larger examples.

>>> On the other hand, if interface references point to a different address 
>>> than class references, you need to store offsets somewhere, have to 
>>> modify the address on every call, need to handle implicit conversions 
>>> when passing function boundaries, etc. etc.
>>
>> This technique I'm used to. It's called thunking and I believe it's the 
>> standard
>> way of implementing MI and/or interfaces. That is, when a class 
>> implements an
>> interface method it makes a thunk to adjust the 'this' pointer before 
>> calling
>> the actual class method. So when you have an interface A and class C and 
>> call a
>> method f in A that is implemented in C the slot in the vtable for f 
>> (which takes
>> an A) calls the thunk to adjust the A to a C and then the thunk jumps to 
>> the
>> method (which takes a C).
>
> Well, I think there's a significant difference between MI and interfaces 
> in that interfaces only allow methods, while with MI you also have fields 
> to think of. Having to basically make a function call for each field 
> access would indeed be too inefficient, but it's not the same case with 
> methods, because the call itself usually takes only a (very) small part of 
> total method execution time.

In general I agree function call speed isn't a big deal for interfaces but 
it isn't unusual to have an interface that abstracts out a field lookup (eg, 
getLength). For those the body of the implementation would be very simple. 
I'm curious if the double lookup technique has been tried in practice and 
what the impressions were.