Bugzilla

I tested capturing a profile with the Media preset while playing a video on Youtube on my own phone.
In all cases the new code was capturing the profile faster. As I expected the magnitude of the difference depends on the size of the profile.

Each time I give 2 numbers. The base time is when I click the "capture" button. The first measurement is when the button turns back to blue. The second measurement is when the profile opens in the browser. I think (but it would be good to check) that the first measurement is the capture time on device, while the second part is when the profile data is transfered.

For a 20-second profile:
old: 6s, then 14s
new: 5s, then 9s

For a 30-second profile:
old: 9s puis 20s
new: 5s puis 10s

For a 1-minute profile:
old: 16s then 1:03s
new: 14s then 24s

TBH I expected that the capture time could be longer, because now we're gzipping the profile on-device while previously it wasn't. But it looks like that gzipping it provides some improvement too. Or it's possible that it's just the matter of using a plain buffer rather than a JS object when handling the data on the devtools server layer.

I tested capturing a profile with the Media preset while playing a video on Youtube on my own phone.
In all cases the new code was capturing the profile faster. As I expected the magnitude of the difference depends on the size of the profile.

Each time I give 2 numbers. The base time is when I click the "capture" button. The first measurement is when the button turns back to blue. The second measurement is when the profile opens in the browser. I think (but it would be good to check) that the first measurement is the capture time on device, while the second part is when the profile data is transfered.

For a 20-second profile:
old: 6s, then 14s
new: 5s, then 9s

For a 30-second profile:
old: 9s puis 20s
new: 5s puis 10s

For a 1-minute profile:
old: 16s then 1:03s
new: 14s then 24s

TBH I expected that the capture time could be longer, because now we're gzipping the profile on-device while previously we weren't doing that. But it looks like that gzipping it provides some improvement too. Or it's possible that it's just the matter of using a plain buffer rather than a JS object when handling the data on the devtools server layer.

I tested capturing a profile with the Media preset while playing a video on Youtube on my own phone.
In all cases the new code was capturing the profile faster. As I expected the magnitude of the difference depends on the size of the profile.

Each time I give 2 numbers. The base time is when I click the "capture" button. The first measurement is when the button turns back to blue. The second measurement is when the profile opens in the browser. I think (but it would be good to check) that the first measurement is the capture time on device, while the second part is when the profile data is transfered (the second is is cumulative, so it includes also the capture). 

For a 20-second profile:
old: 6s, then 14s
new: 5s, then 9s

For a 30-second profile:
old: 9s, then 20s
new: 5s, then 10s

For a 1-minute profile:
old: 16s then 1:03s
new: 14s then 24s

TBH I expected that the capture time could be longer, because now we're gzipping the profile on-device while previously we weren't doing that. But it looks like that gzipping it provides some improvement too. Or it's possible that it's just the matter of using a plain buffer rather than a JS object when handling the data on the devtools server layer.