On 2006-03-14 14:12 EST, Jim Grandy wrote: > Thanks! I've made changes in response to this and will resend soon. > > On Mar 14, 2006, at 10:27 AM, P T Withington wrote: > >> In LaszloEvents where you are adding the event name (105 and 219), >> the if clause is supposed to keep you from adding it every time >> you register, but you are testing a prop that you are not setting, >> so you will. You either need to set the sender field too or test >> the name field. Too bad we don't have support for simple compile- >> time expressions... (Gee, you could just pass them to rhino... >> hm...). >> > Ouch, yeah, copy-paste error. I've changed the name of the > attribute to _dbg_profileName (best to avoid conflicting with the > debug name) and tested for it alone.
That's the right thing, since the debug case is trying to preserve more information than you can use in the profile case (see next comment). >> I'm thinking you probably want the sender and the event name >> anyways for profiling. Presumably it will be more informative to >> log sender.event in your call/return, no? >> > But then it would be hard to aggregate all event dispatches of a > given name. The call graph tells you who the sender is, anyway, right? 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. 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.) 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. >> Is there any benefit to logging a 'start' event too? (I don't see >> a corresponding 'done' event). I only did that for nodes because >> they are initialized asynchronously (so you can't log that in the >> call/return because it will screw up the graph). >> > Thanks for the tip; I took that out. >> On 2006-03-14 12:27 EST, Jim Grandy wrote: >> >>> Change 40569 by [EMAIL PROTECTED] on 2006/03/14 09:25:44 *pending* >>> >>> Summary:Improved profiling for sendEvent, remove some flasm, >>> optimize a few basic calls >>> >>> Technical Reviewer: ptw (pending) >>> QA Reviewer: mdavis (pending) >>> Doc Reviewer: (pending) >>> >>> Tests:runlzunit passes >>> >>> Affected files ... >>> >>> ... //depot/lps-dev/WEB-INF/lps/lfc/core/LzNode.as#30 edit >>> ... //depot/lps-dev/WEB-INF/lps/lfc/events/LaszloEvents.as#16 edit >>> >>> >>> <changeset-40569.zip> >> > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
