The idea is to be able to specify, for a particular function, that any stack traces that pass through that function should be excluded from the profile.

I currently have a list of these built in: https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/lib/symbolicate.js#L10 Are you suggesting that we add more to the default list or let the user specify is own?

I want, as the user, to specify my own. Furthermore, I want the action to be undoable easily. A common use case for me, say, is excluding everything under nsPresShell::Paint or whatnot so I can focus on the parts of the profile I actually care about.

I tried to profile the display of tweets in Thunderbird, and I'm seeing lots of samples identified as being in "Jetpack: Gecko Profiler". This seems to be because some code of the profiler observes the document-element-inserted notification fired by nsContentSink::NotifyDocElementCreated. My code calls DOMParser.parseFromString once for each tweet, causing lots of documents to be created and so lots of document elements are inserted. I expected that putting -NotifyDocElementCreated in the filter box of the profiler UI could filter out samples containing NotifyDocElementCreated in the stack (similar to the usage of - in search engines to exclude results containing a keyword), but comment 1 here saying that there's a hard coded list of function names to ignore makes me wonder if something shouldn't be added to that list to handle this situation. Here is the profile: http://people.mozilla.com/~bgirard/cleopatra/?report=16e98d64ff2b3a2ecd20a4feca28fb213398f813

(In reply to Florian Quèze [:florian] [:flo] from comment #3) > I tried to profile the display of tweets in Thunderbird, and I'm seeing lots > of samples identified as being in "Jetpack: Gecko Profiler". I'm not recognizing anything in the 'Jetpack: Gecko Profiler' samples. Either code is from the addon SDK or the profiler doesn't match the jetpack id to the right extension. See if you can find in which extension the JS source file comes from. > > This seems to be because some code of the profiler observes the > document-element-inserted notification fired by > nsContentSink::NotifyDocElementCreated. > > My code calls DOMParser.parseFromString once for each tweet, causing lots of > documents to be created and so lots of document elements are inserted. > I expected that putting -NotifyDocElementCreated in the filter box of the > profiler UI could filter out samples containing NotifyDocElementCreated in > the stack (similar to the usage of - in search engines to exclude results > containing a keyword), but comment 1 here saying that there's a hard coded > list of function names to ignore makes me wonder if something shouldn't be > added to that list to handle this situation. The filter does the opposite. It filter samples that do not contain that string making it useful for quickly seeing for example when you 'Reflow'. We still don't have a way to exclude functions from the profile. > > Here is the profile: > http://people.mozilla.com/~bgirard/cleopatra/ > ?report=16e98d64ff2b3a2ecd20a4feca28fb213398f813

(In reply to Benoit Girard (:BenWa) from comment #4) > (In reply to Florian Quèze [:florian] [:flo] from comment #3) > > I tried to profile the display of tweets in Thunderbird, and I'm seeing lots > > of samples identified as being in "Jetpack: Gecko Profiler". > > I'm not recognizing anything in the 'Jetpack: Gecko Profiler' samples. > Either code > is from the addon SDK or the profiler doesn't match the jetpack id to the > right extension. > See if you can find in which extension the JS source file comes from. The "<Anonymous> @ events.js:44 Jetpack: Gecko Profiler" line seems to be from the file resources/api-utils/lib/system/events.js inside the gecko profiler add-on (so part of the addon SDK). > > I expected that putting -NotifyDocElementCreated in the filter box of the > > profiler UI could filter out samples containing NotifyDocElementCreated in > > the stack (similar to the usage of - in search engines to exclude results > > containing a keyword)[...] > > The filter does the opposite. It filter samples that do not contain that > string making it useful for quickly seeing for example when you 'Reflow'. We > still don't have a way to exclude functions from the profile. I understood that, but I expected that prepending "-" to the string could be used to reverse the behavior. Would this be difficult to add?

(In reply to Florian Quèze [:florian] [:flo] from comment #5) > > > I expected that putting -NotifyDocElementCreated in the filter box of the > > > profiler UI could filter out samples containing NotifyDocElementCreated in > > > the stack (similar to the usage of - in search engines to exclude results > > > containing a keyword)[...] > > > > The filter does the opposite. It filter samples that do not contain that > > string making it useful for quickly seeing for example when you 'Reflow'. We > > still don't have a way to exclude functions from the profile. > > I understood that, but I expected that prepending "-" to the string could be > used to reverse the behavior. Would this be difficult to add? Florlan, do you still see this issue?

(In reply to Wayne Mery (:wsmwk) from comment #6) > Florlan, do you still see this issue? The add-on SDK consuming massive amounts of CPU when DOMParser.parseFromString is used is a problem that has been fixed a long time ago.

This was implemented in https://github.com/devtools-html/perf.html/pull/693 .