Closed
Bug 1053109
Opened 10 years ago
Closed 8 years ago
geckoprofiler.xpi always shows samples that relate to time spent launching Cleopatra UI.
Categories
(Core :: Gecko Profiler, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jujjyl, Unassigned)
References
Details
The current procedure for capturing a geckoprofiler.xpi profile is
1. Stop the profiler (see bug #1053101)
2. Navigate the page to the state you want to have at profiling startup.
3. Start the profiler
4. Run the page for a while and perform the actions you wanted to profile.
5. Click on the Analyze button on the profiler.
A problem with this is that this way the graph that shows up always contains samples that relate to the browser loading up and displaying the Cleopatra UI, because the profiler is still active during step 5. This adds new steps
6. Identify in the sample timeline where the Analyze button was clicked.
7. Drag-select an interval on the timeline that does not contain the unwanted samples that relate to loading up Cleopatra UI to zoom in the actual relevant results.
It would help if the procedure was instead:
1. Navigate the page to the state you want to have at profiling startup.
2. Start the profiler
3. Run the page for a while and perform the actions you wanted to profile.
4. Click on the Stop button on the profiler. This would save the captured profile.
5. Click on the Analyze button on the profiler to view the captured profile.
This way the profile would not contain any samples from the time period when the Cleopatra UI was loading up.
Component: Developer Tools: Profiler → Gecko Profiler
Product: Firefox → Core
Comment 1•10 years ago
|
||
I've submitted a pull request to the Gecko-Profiler-Addon repository that makes us retrieve the profile when the hotkey is pressed instead of waiting for cleopatra to load: https://github.com/bgirard/Gecko-Profiler-Addon/pull/82
Comment 2•10 years ago
|
||
Interestingly, I still this with 1.15.7, though the PR says this shipped in 1.15.4. Does this work for everybody else?
Comment 3•10 years ago
|
||
You're right, it's no longer working. Benoit undid it in https://github.com/bgirard/Gecko-Profiler-Addon/commit/c0a59f2747d02a1a804509e607ffe69fc3b461c7 trying to make automated tests succeed, and it fixed the issue, though I don't know why.
Benoit, how can I make travis run the tests on experimental patches? I guess it runs on pull requests, and I could just keep sending those until I've found the problem.
Flags: needinfo?(bgirard)
Comment 4•10 years ago
|
||
Yea, I've been doing pushes to get Travis to run. PR should be working. I can't find any permissions on Travis-CI that I can give out to do retiggers, I'm not sure how that works.
Flags: needinfo?(bgirard)
Comment 5•10 years ago
|
||
Thanks! I'll try that then.
Comment 6•8 years ago
|
||
This is fixed. The new add-on calls getProfileDataAsync before opening the tab.
For a while, this wasn't sufficient to fix this due to bug 1321617, so we added a workaround in the add-on for this in https://github.com/devtools-html/Gecko-Profiler-Addon/pull/9 , but bug 1321617 is now also fixed.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•