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)

x86
All
defect
Not set
normal

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
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
Interestingly, I still this with 1.15.7, though the PR says this shipped in 1.15.4. Does this work for everybody else?
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)
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)
Thanks! I'll try that then.
Blocks: 1329163
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.