Extension profiling mechanism for profiling bad things caused by JS

RESOLVED WONTFIX

Status

Firefox Build System
Source Code Analysis
RESOLVED WONTFIX
8 years ago
4 months ago

People

(Reporter: (dormant account), Assigned: sfink)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ts])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
sewardj helped me come up with an "easy" way to measure addon overhead. Using hooks like this provided in bug 507012, we can measure when we leave js code and call into c++(or just more js code).
The trick is to use a log to log every known expensive operation(ie nspr read operations, sqlite queries, reflows, xpconnect crossings). 
Then from the pre-execution hook one would mark the current position in the log, exit the hook. Then the post-execution hook would compare the current log position and record that particular function call as expensive.

This isn't meant to be a cheap profiling mechanism. The aim to run firefox with any given extension(or chrome js code) in a special mode that would provide a report of things that it does badly.
(Reporter)

Updated

8 years ago
Whiteboard: [ts]
(Reporter)

Updated

8 years ago
Blocks: 550242
OS: Linux → All
Hardware: x86 → All

Comment 1

8 years ago
tomcat has a system for doing quick tests on addons to do santity checks and find basic problems, and the "addon verifier" is run to look for evil code patterns in addon js.

Those are two possible places where a tool like this might be plugged in or experimented with.

Comment 2

8 years ago
This bug has some overlap with bug 480735 - perhaps a timer JS API is needed so ext devs can hook into our startup timeline?
(In reply to comment #1)
> tomcat has a system for doing quick tests on addons to do santity checks and
> find basic problems, and the "addon verifier" is run to look for evil code
> patterns in addon js.
> 

yeah, just need some information what kind of addons we want to test (like the top x addons) or special kind addons (like as example toolbars etc)
Assignee: nobody → sphink
Depends on: 580063
A prototype of one cut of this is available at http://people.mozilla.com/~sfink/slowcalls-proto/slowcalls.html

Comments welcome.
Fantastically sweet.  I especially dig the SVG graph!

It might be helpful to target your data output at the GWT SpeedTracer UI before going much further on the UI.  They have a documented dump format and their UI is very polished, which I think would be useful to help polish and/or filter the data you generate.  Additionally, when I blogged about using SpeedTracer on mozilla (using systemtap-sourced data), the GWT lead seemed very willing to help me if I wanted to pursue things further.

The dump format:
http://code.google.com/webtoolkit/speedtracer/data-dump-format.html

The template I used to make the speedtracer extension want to open my files:
http://hg.mozilla.org/users/bugmail_asutherland.org/tb-test-help/file/680111e1a916/systemtap/speedtracer/template.html

My blog post for greater context:
http://www.visophyte.org/blog/?p=508

Note that I'm not advocating for long-term usage of SpeedTracer; I just think it's a great existing resource.  (Both ideologically and from a community resources perspective, I think it would be preferable to use a written-in-JS rather than compiled-to-JS solution.)
Ah, yes. Thank you for those posts! I had already read those a couple of months ago, and even played with it a little. I fully agree with your conclusions: (1) SpeedTracer seems like the best thing out there for a first cut at visualizing detailed performance data; and (2) it's not a great long-term solution because of the GWT layer.

But this bug is more targeted. It's about an in-browser mechanism that produces some sort of "bad behavior" report for an extension. Requiring SpeedTracer as a dependency is really stretching the builtin-ish nature of the request.

Note that the current implementation requires an external script to process the log files, and so is equally inadequate. I'm slowly working on porting it to a more internal solution. But yes, you are right that I shouldn't bother with much more UI stuff.

I should file a bug on the SpeedTracer (or equivalent) integration, since I would really like to get something like that as well.

<offtopic>

I also followed your blog links to your earlier systemtap work, which is something else I'm working on. You've got some great stuff there that I wish I'd known about earlier. I'm surprised you didn't run into bug 574403.

Oh! You probably weren't using --enable-dtrace, were you? You don't care about the USDT probes.
Created attachment 482326 [details]
Temporary script to produce slowcalls UI as output

Attaching the current version of my processing script here so I can point to it from https://wiki.mozilla.org/index.php?title=Using_SlowCalls
Created attachment 514106 [details]
Temporary script to produce slowcalls UI as output

Minor formatting tweak, switch most time units to fractional ms instead of us.
Attachment #482326 - Attachment is obsolete: true
I never really deployed this anywhere, and it has long since bitrotted away, I'm sure.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.