Re: objective-c: how slow ?

[Malmberg]

[snip]
> An alternative could be placing a full IC
> code inline but with the first instruction a jump to the patching routine, 
> which
> will restore the first instr. of the IC and update the values known only at 
> runime.

There are threading issues with that. A full jump is 5 bytes, which is
more than can be patched atomically (or are the 80 bit FP stores
atomic?).

> > 0.5-1 cycles. The unconditional jump is cheap, and lack of conditional
> > call instructions means that the stub can be slightly more efficient
> > than the IC ('call stub;compare;jz method;jmp lookup' instead of
> > 'compare;jmp call_stub;call lookup;jmp cont;call_stub:call
> > method;cont:').
> 
> You can code the stub like that in the inline code too, you would save
> 0.5-1 cycles but it would require compiler changes.

No you can't, since at some point you have to put the return address on
the stack. Manually pushing the return address costs (for whatever
reason) ~15 cycles, so that's not an option. Calling a local stub will
be no more efficient than calling the outline stub.

> Anyway you would be writing in the text segment, which would most
> probably arise in a copy on write page fault.

That will be a problem with any IC. A second level of indirection would
help a lot, but would probably cost ~0.5 cycles.

>   Your solution is more easy to implement because the compiler itself needs 
> not
> to be changed but can give serious performance problems that can be hard to
> predict because they depend of the execution profile of the program.

I don't think they'd be hard to predict. After calling a runtime
function, every call to those method implementations causes the caller
to be patched (memory[return_address-0x4]=selector->stub_adr). There'll
be a 4k page copy the first time for each page, but if you can't live
with that, you simply can't use selfmodifying code (or you could load
the entire program and its libraries non-shared, which would be
predictable but cost memory and load speed).

[snip]
> > Doesn't forwarding and DO count as delegation?
> 
> Not really. Delegation uses the delegate to lookup the method
> but forwards the original receiver.
> (One example is better than a thousand words. see attachment)

Forwarding doesn't do that (currently), but it would be trivial to add a
flag that tells NSInvocation to set self of the called method to the
object doing the forwarding. If that isn't fast enough, it would be
possible to add a objc_add_delegate_for_class(someClass,theDelegate)
function that added all methods in theDelegate to someClass if it didn't
already have a method for that selector. You could even do it for an
individual object. It's a bit dangerous, though, since the receiver
probably expects self to be of the correct type.

[snip]
> I admit I don't know in detail the lookup mechanism in the objc runtime

In short, each selector gets an index, and each class has an array of
implementations for selectors (implemented as a two-level sparse array,
but that makes no difference). The lookup uses the index to get the
selector from the array (and if there isn't one, it goes on to do
forwarding etc.).

- Alexander Malmberg