[Laszlo-dev] For Review: Change 40569 Summary:Improved profiling for sendEvent, remove some flasm, optimize a few basic calls
P T Withington
ptw at openlaszlo.org
Tue Mar 14 15:37:49 EST 2006
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.
More information about the Laszlo-dev