Closed Bug 470116 Opened 11 years ago Closed Last year

Component for timing execution of js and others

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: taras.mozilla, Assigned: taras.mozilla)

References

Details

Attachments

(4 files, 5 obsolete files)

No description provided.
Attached patch timing component (obsolete) — Splinter Review
This registers early on and starts timing js calls..Any call slower than 1ms is flagged. 
Calls are printed out to console in a "stack" form. This is achieved with a counter(gMeasureDepth) which tracks nesting level(not thread safe). Any suggestions would be appreciated.
Sample output:
496ms     CallHook (anonymous) chrome://browser/content/WidgetStack.js:1177 1.1ms
500ms     CallHook (anonymous) chrome://browser/content/WidgetStack.js:1177 1.3ms
500ms      CallHook (anonymous) chrome://browser/content/WidgetStack.js:1281 1.3ms
500ms     CallHook (anonymous) chrome://browser/content/WidgetStack.js:1177 1.6ms
500ms    CallHook (anonymous) chrome://browser/content/WidgetStack.js:308 6.2ms
500ms   CallHook WidgetStack chrome://browser/content/WidgetStack.js:255 6.2ms
Assignee: nobody → tglek
Attached patch timing component (obsolete) — Splinter Review
missed a file
Attachment #353562 - Attachment is obsolete: true
(In reply to comment #1)
> Created an attachment (id=353562) [details]
> timing component
> 
> This registers early on and starts timing js calls..Any call slower than 1ms is
> flagged. 
> Calls are printed out to console in a "stack" form. This is achieved with a
> counter(gMeasureDepth) which tracks nesting level(not thread safe). Any
> suggestions would be appreciated.

Is it possible to just walk the JS stack frames up to the root and count them to compute the stack depth?  I know you can do this from JS so I assume it's possible from C++ as well.  This will be a little bit slower, but it ought to be threadsafe.  Just a thought.
i'd rather use tls or something for the counter, since it's handy to be able to place these into C++ code and see when they are called from js
Blocks: 459117
Attached patch timing componentb (obsolete) — Splinter Review
This version should work pretty well. It still doesn't do TLS, but I haven't had to time stuff across threads yet, so it's ok.
To use set MOZ_STOPWATCH environment variable, when it's not set the component doesn't do anything.
Attachment #353565 - Attachment is obsolete: true
Attached patch timing component(using tls) (obsolete) — Splinter Review
Attachment #355626 - Attachment is obsolete: true
This is a little bit of a hack. It enables the timing component to be notified when a fastcall is run. This is useful when there is dom code(which often uses fastcalls) where a dom method is taking up most of the time, but it's unclear which. This made solving the resize issue much easier.
This is another convenience, to use it get a log for something you want to analyze fennec js overhead in, then run the script. This does a frequency count and duration of js function calls.
Attached patch latest component diff (obsolete) — Splinter Review
This one logs to per-thread files
Attachment #358203 - Attachment is obsolete: true
Attachment #390036 - Attachment is obsolete: true
Don't think it is still relevant!
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.