Closed
Bug 1141283
Opened 9 years ago
Closed 9 years ago
Compensate for stackwalk duration and sleep overhead when determining sampler sleep time
Categories
(Core :: Gecko Profiler, defect)
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
Details
Attachments
(1 file)
5.71 KB,
patch
|
BenWa
:
review+
|
Details | Diff | Splinter Review |
I didn't touch the Windows implementation because apparently we're not using SleepMicro there yet.
Attachment #8574857 -
Flags: review?(bgirard)
Comment 1•9 years ago
|
||
Have you looked into the worse case scenarios when the sampling rate is faster than the sample duration?
Assignee | ||
Comment 2•9 years ago
|
||
Good point, no I haven't.
Assignee | ||
Comment 3•9 years ago
|
||
I've tried this locally on Mac now, by setting the sample interval to 0.0002 and profiling main thread + compositor thread. This resulted in a "real interval" of 0.02ms, so I suppose the profiling overhead of stackwalking+js on Mac is about 0.01ms per thread on this machine. With that profiling interval, the browser is very slow but still usable; simple pages scroll at 30fps, a complex cleopatra tree scrolls at 1fps.
Updated•9 years ago
|
Attachment #8574857 -
Flags: review?(bgirard) → review+
Assignee | ||
Comment 4•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/1ec1ec82f440
Comment 5•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1ec1ec82f440
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•