Closed Bug 1152606 Opened 6 years ago Closed 6 years ago

As more recordings are created, device gets slower to reply

Categories

(DevTools :: Performance Tools (Profiler/Timeline), defect, P1)

defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jryans, Unassigned)

References

Details

Attachments

(1 file)

Attached image recordings-grow.png
Build ID               20150408010203
Gaia Revision          109cb8bbfcecc94fb1a024092192ecbfc6b77bec
Gaia Date              2015-04-08 23:34:21
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/078128c2600a
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150408.044148
Firmware Date          Wed Apr  8 04:41:59 EDT 2015
Bootloader             L1TC10011880

STR:

1. Connect to device in WebIDE via USB
2. Choose "System" as the app to inspect
  * Enable access to certified apps first if needed[1]
3. Go to new Perf tool
4. Start and stop profiling (attempt to measure only a few seconds)
5. Wait for profile to be retrieved
6. Repeat 4 - 5 several times

ER:

Each profile should be about the same length.

AR:

Each time you profile again, it takes longer to actually stop and download.  Also, the device basically hangs during the download process.

[1]: https://developer.mozilla.org/en-US/docs/Tools/WebIDE/Running_and_debugging_apps#Unrestricted_app_debugging_%28including_certified_apps.2C_main_process.2C_etc.%29
Summary: As more profiles are created, devices gets slower to reply → As more recordings are created, devices gets slower to reply
Summary: As more recordings are created, devices gets slower to reply → As more recordings are created, device gets slower to reply
This happens on desktop as well. I believe it's due to more samples to filter out. Bug 1145824 should increase the performance of this operation as it's handled on the platform side, but there's only so much we can do. Bug 1144439 for showing when a profile is being 'stopped', and the new bug for that, showing a throbber, bug 1146239, I think will help here
I don't understand… why is it getting slower? Aren't samples thrown away?
Flags: needinfo?(jsantell)
Blocks: perf-tool-v2
Flags: needinfo?(jsantell)
Priority: -- → P1
Flags: needinfo?(jsantell)
as the circular buffer grows, the longer it takes to get serialized, passed to the actor and then passed to the client. on the first recording, the buffer is only partially full -- as more and more recordings happen, the buffer gets close to being full which should peak the max delay on recording. Currently, we always receive the entire buffer, and filter out the times on the client, which means long delays as we approach the full buffer.

bug 1154115 will reduce the time it takes to serialize and transfer, and bug 1145824 will move the filtering of samples to SPS profiler rather than the client, so will be faster filtering, and less data moving over the protocol. I think these two will fix this issue, hopefully.
Flags: needinfo?(jsantell)
Not sure if it's possible, but can't we just empty the buffer after every recording?
The buffer is shared throughout all of Firefox -- so any toolbox, or any addon (Gecko Profiler) can be using it at any time, so clearing out the buffer after recording could destroy another profile. There's another bug somewhere that Shu was looking at to improve the profiler to make it a bit more robust for multiple recordings, but I think the two bugs mentioned in comment 3 will go a long way
With bug 1145824 landed, tapping my foot to the beat of some death metal, starting and stopping recordings, the duration of each recording is fairly close. I think this one's solved.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.