Open Bug 1436022 Opened 2 years ago Updated 10 days ago
Track parser worker performance on DAMP
It looks like the performance issue behind bug 1432051 isn't covered by DAMP. One of the symptomatic code is the message event sent between the worker and the parent process. You can spot that by looking for "MessageEventRunnable". It will display the processing of message event in both sides. On the first side, it will clone the json object into a structured clone, and on the other side it will do the same, the other way around. From bug 1432051 comment 12 report, you get this profile: https://perfht.ml/2sbm6qx You can see about 500ms of computation in both threads. Now, here is a profile of custom.debugger DAMP test: https://perfht.ml/2seKU0U MessageEventRunnable is only 80ms on a slow VM. So the message transfered in DAMP test is significantly smaller than bug 1432051 comment 12 usecase. Also, I added some user timing to trace the time it takes to compute "getSymbols" in the worker and it only last 315ms (whereas debugger.open last for 12s, so it isn't a significant part of debugger opening) At the end, I'm not sure we stress parser-worker codepath enough to highlight evident regressions. I don't know exactly how to best stress it out? Should we just increase the bundle size or is there any special pattern the bundle should have? Or something to do in debugger UI to use more parser-worker features?
Summary: Tracker parser worker performance on DAMP → Track parser worker performance on DAMP
No longer blocks: dbg-69
You need to log in before you can comment on or make changes to this bug.