Message forwarding using DNU

Hi,
        Days ago I was talking with a friend, and thinking about the
performance impact of using "proxies", or "wrappers" through the
message forwarding using the #doesNotUnderstand:

        Even if the "Proxy" is a ProtoObject, where the method lookup
should be shorter, what would be the performance impact, or indeed
how big, of working in that way? (using DNU).

        Best regards

--
Esteban A. Maringolo
[hidden email]

Esteban,

>     Days ago I was talking with a friend, and thinking about the
> performance impact of using "proxies", or "wrappers" through the message
> forwarding using the #doesNotUnderstand:
>
>     Even if the "Proxy" is a ProtoObject, where the method lookup should
> be shorter, what would be the performance impact, or indeed how big, of
> working in that way? (using DNU).

What do you plan to proxy?  How often would you send messages to the
proxies?  FWIW, my sense is that proxies are most valuable for things
(network connections, SQL, IPC in general, etc.) that tend to be on the
slow side (in computer terms anyway), so the overhead of the proxy is
probably not limiting.

If you are proxying Smalltalk objects in your image, then you might want
to ask whether there is a better way.  Even then, it might be justified.
  If it makes your life easier, build it and profile the result.  If
it's too slow for its own good, then look for another mechanism.  It
might turn out to be as simple as adding specific methods to your
proxies; profiling would tell you which ones are likely to benefit you.
  My guess is that it will be fine.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab escribió:
> Esteban,

>>     Days ago I was talking with a friend, and thinking about the
>> performance impact of using "proxies", or "wrappers" through the
>> message forwarding using the #doesNotUnderstand:
>>     Even if the "Proxy" is a ProtoObject, where the method lookup
>> should be shorter, what would be the performance impact, or indeed how
>> big, of working in that way? (using DNU).

> What do you plan to proxy?  How often would you send messages to the
> proxies?  FWIW, my sense is that proxies are most valuable for things
> (network connections, SQL, IPC in general, etc.) that tend to be on the
> slow side (in computer terms anyway), so the overhead of the proxy is
> probably not limiting.

What I want to know is the overhead, and I'm asking to know if
somebody already measured it, not a solution to a problem. The
lookup for the activation of a method in a Dialog subclass won't be
the same as the lookup in a ProtoObject subclass.
BTW, If it is a wrapper, be sure it will  receive several messages.

Thanks.

--
Esteban A. Maringolo
[hidden email]

Esteban,

> What I want to know is the overhead, and I'm asking to know if
> somebody already measured it

Difficult to measure in the general case because there isn't a general case.
For instance, how much logic would you have in the #doesNotUnderstand method ?

Still, by way of a ball-park estimate, here are some numbers.  Take them (as
always with numbers, especially with micro-benchmarks) with a GREAT DEAL of
salt...

Given
    o := OrderedCollection new.
    20 timesRepeat: [o add: 'Hi there'].

And
    p := AAATempProxy for: o.

(where AAATempProxy>>doesNotUnderstand: just reads:

    ^ aMessage forwardTo: target.

I.e. it is about as simple an implementation as you can get -- which is
probably not realistic)

Then

    o last

takes around 395 nanoseconds on my machine (1.5 Gz WinXP).

    p last

takes around 890 nanoseconds.

And, if I add #last to AAATempProxy (implemented as a direct send of #last to
its target), then

    p last

 takes around 475 nanoseconds.

So -- for this particular example -- a DNU adds around as much overhead as a
single lookup in an OrderedCollection, whereas a more elaborate scheme (say
involving dynamic creation of forwarding methods) could cut that down to about
a quarter.  But, since the overhead is not exactly large to start with, it's
probably not worth the fuss and bother.

    -- chris

Chris Uppal escribió:
> Esteban,

>>What I want to know is the overhead, and I'm asking to know if
>>somebody already measured it

> Difficult to measure in the general case because there isn't a general case.

Yes, I know that. :-)

> For instance, how much logic would you have in the #doesNotUnderstand method ?

if it's a wrapper, it would just redirect messages.
Or... take as an example an AspectBuffer, which just redirects
messages to it's subject copy.

> Still, by way of a ball-park estimate, here are some numbers.  Take them (as
> always with numbers, especially with micro-benchmarks) with a GREAT DEAL of
> salt...

Of course, numbres are just a kind of lie (or reality distorsion) :-)

> So -- for this particular example -- a DNU adds around as much overhead as a
> single lookup in an OrderedCollection, whereas a more elaborate scheme (say
> involving dynamic creation of forwarding methods) could cut that down to about
> a quarter.  But, since the overhead is not exactly large to start with, it's
> probably not worth the fuss and bother.

I didn't think in that, dinamic creation of forwarding methods would
  speed up as the system is up un running, only optimizing where
necessary. The optimization would only "alive" during a session, bu
would be sufficient.

Thanks Chris, I just was looking for few numbers. Of course, i could
do it by myself, but i'm lazy today.

TIA.

--
Esteban A. Maringolo
[hidden email]

Esteban A. Maringolo wrote:

The overhead depends on the VM implementation.  Using a jit and
polymorphic in-line caches one can bring the overhead of a DNU down to
the order of an extra call and the allocation of the message argument to
doesNotUnderstand:.

In blue book VMs a doesNotUnderstand: always incurs the cost of a full
traversal of the class hierarchy looking for the non-understood message
(because one cannot enter into the method lookup cache what is not
there).  But with a PIC one can remember that a message is not
understood for a particular receiver class, cache the target method for
doesNotUnderstand: for that receiver class, and call a run-time routine
to create the message and jump to the target routine.  vw5i.3 (which has
PICs) is about 5 times faster to deliver a doesNotUnderstand: than 5i.2
and earlier (which did not).
--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Hi Elliot,

Eliot Miranda escribió:
> Esteban A. Maringolo wrote:

>> What I want to know is the overhead, and I'm asking to know if
>> somebody already measured it, not a solution to a problem. The lookup
>> for the activation of a method in a Dialog subclass won't be the same
>> as the lookup in a ProtoObject subclass.
>> BTW, If it is a wrapper, be sure it will  receive several messages.

> In blue book VMs a doesNotUnderstand: always incurs the cost of a full
> traversal of the class hierarchy looking for the non-understood message
> (because one cannot enter into the method lookup cache what is not
> there).  But with a PIC one can remember that a message is not
> understood for a particular receiver class, cache the target method for
> doesNotUnderstand: for that receiver class, and call a run-time routine
> to create the message and jump to the target routine.  vw5i.3 (which has
> PICs) is about 5 times faster to deliver a doesNotUnderstand: than 5i.2
> and earlier (which did not).

What is a PIC?
Does VW 7.3 support PIC?

Thank you.

--
Esteban A. Maringolo
[hidden email]