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? 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. 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.
|
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
