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

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?

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.

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.