Apparently, field trials are activated only when you call base::FeatureList::IsEnabled(), which means that the use-new-media-cache will only get activated when playing a video, and on android, only if spitzer is on.
This means that the population in the above graph is 100% spitzer, which explains some things, but not everything. (Like, why don't we see this memory increase on other platforms?)
It's possible that this CL: https://codereview.chromium.org/1754893006/ which was not merged back to M50 afaik, fixes the memory usage, which could explain why I don't see the issue on M51-CANARY-{M,W}
So I looked and I looked, but could not find any sign of this happening on desktop platforms. However, we now have enough M51-Android data that it looks like it is happening there.
My new theory is that the difference comes from differences in lifetime. The experiment is activated when we play a video, and the memory usage is expected to be slightly higher while playing a video (and for a short time after). On android, I suspect that the renderer is often killed shortly after playing the video, so in the UMA stat, we primarily see the time where the memory usage is higher. On other platforms, the renderer may live longer and we primarily see UMA stats where there is no difference.
But isn't this just comparing BufferedDataSource vs MultiBuffer? I.e. the Disabled group is only marked when a WebMediaPlayer is created with BufferedDataSource and the Enabled group is only marked when a WebMediaPlayer is created with MultiBuffer.
It follows that they should both have the same lifetime then right? I.e. any differences in renderer usage on desktop vs android should be moot since the comparison accounts for this.
cc:asvitkine in case he has any insight to add.
My theory in #5 wasn't meant to explain why the memory usage goes up on android. It's meant to explain why it doesn't go up on other platforms. I suspect that the majority of the change in this graph is recorded after the video has ended, as BufferedDataSource would immediately free all the memory, while the multibuffer will free memory lazily. This might also explain why the graph has a somewhat odd shape.
I see. We should be able to verify that by nuking the lazy-release behavior for a release and seeing what the performance looks like.
Can you refresh my memory on how the lazy release works? I wasn't able to find the code off hand.
Hmm, apparently, I can't find it either.
At some point I had piece of code that would call Prune() every now and then to free memory, but that seems to have been lost (or misplaced) in some revision.
Using more memory makes sense if it's not freed, but then, why doesn't it show up on other platforms?
Maybe renderers live longer? This would be consistent with the primarily single-tab browsing experience on Android.
It sounds like for now we should at least restore the pruning functionality.
Comment 1 by hubbe@chromium.org
, Mar 18 2016