[Laszlo-dev] For Review: Change 40569 Summary:Improved profiling for sendEvent, remove some flasm, optimize a few basic calls

[P T Withington]

On 2006-03-14 14:47 EST, Jim Grandy wrote:

>
> On Mar 14, 2006, at 11:33 AM, P T Withington wrote:
>
>> Er, the call graph will tell you that sendEvent was called.  I got  
>> the impression that what you are trying to get at here is to see  
>> _what_ event is being sent.  The 'sender' of the event is an  
>> instance, and you might also be interested in which particular  
>> instance is sending the event.  If so, you would want to add that,  
>> or not.  It would be the difference between seeing that the  
>> 'onclick' event was sent and #button32.onclick was sent.  Depends  
>> what level of detail you are looking for.
>>
> Right, my thinking was a little muddy. But still: I think knowing  
> the event dispatch frequency by name is more important than knowing  
> event/sender pair frequencies. The latter still has some  
> usefulness, though. Could I add a nested layer, so event/sender  
> wraps event?
>
> call #button32.onclick
> call onclick
> return onclick
> return #button32.onclick
>
> Or would this be too verbose?

You're call.  I don't know what you are looking for here.  But you  
want the more specific 'call' inside the less specific, right?

>>
>> The trick here is that the sender may not have an id or name, so  
>> perhaps there will be no information there of use.  If you look at  
>> _dbg_name in events, you will see that it uses formatToString,  
>> which preserves the object behind the string so you can inspect it  
>> even if it doesn't have a unique id.  That connection will be lost  
>> in the profile log.  (Clearly if you _do_ want to record the  
>> sender for profiling, convert the sender to a string once a  
>> registration time, not each time the event fires.)
>>
> Plus there's this. But the name as used in the constructor events  
> is still useful, and would work in this context as well.

Debug.__String(sender) is a good compromise.

>>
>> Just to be clear, the reason for similar code in `mvn` is that it  
>> is the shared constructor for _all_ classes.  It was pretty  
>> useless to see that in the call graph, what you really want to see  
>> is what class is getting constructed.  Your change to sendEvent is  
>> similar in spirit, since _all_ events funnel through there, it  
>> doesn't give you any information about what events are used the most.
>>
>> I don't know if there is a pattern here we could exploit more  
>> generally, or if there are just a few methods that are like this  
>> that have to be customized to get useful profiling out of them.  I  
>> guess anytime you see a method at the top of the profile list, you  
>> should think about whether it can be subdivided in this manner.
>