1152606 - As more recordings are created, device gets slower to reply

Status: RESOLVED INVALID

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

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: 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

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

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

Comment 2

[Paul Rouget [:paul]]

I don't understand… why is it getting slower? Aren't samples thrown away?

Comment 3

[Jordan Santell [:jsantell] [@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.

Comment 4

[Paul Rouget [:paul]]

Not sure if it's possible, but can't we just empty the buffer after every recording?

Comment 5

[Jordan Santell [:jsantell] [@jsantell]]

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

Comment 6

[Jordan Santell [:jsantell] [@jsantell]]

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.