Removing WebMediaPlayer MemoryDumpProviders

[Joe Mason]

third_party/blink/renderer/platform/media/web_media_player_impl.cc registers two MemoryDumpProviders, "WebMediaPlayer_MainThread" and "WebMediaPlayer_MediaThread". As best I can tell, these now only log data to UKM:

Memory.Experimental.NumberOfWebMediaPlayers

Memory.Experimental.WebMediaPlayer.Audio

Memory.Experimental.WebMediaPlayer.DataSource

Memory.Experimental.WebMediaPlayer.Demuxer

Memory.Experimental.WebMediaPlayer.Video

They used to also be logged to UMA (except "NumberOfWebMediaPlayers" was named "Memory.Experimental.WebMediaPlayer.Instances"), but the UMA metrics have vanished from histograms.xml so long ago I can't find them in the history. (Or maybe they were never actually recorded to UMA.)

I recently added some metrics to see how long MemoryDumpProviders take to run, and the two WebMediaPlayer providers seem to be outliers. Before I spend time investigating and optimizing them, can they just be removed? Is this UKM data still useful?

Thanks,

Joe

[Dale Curtis]

I think they can probably be removed. I suspect knowing the percentage of active memory that is media allocations is useful, but I haven't needed that recently. The initial metrics were added before Chromium had robust renderer process memory metrics. Probably these take a long time to run because they may scan many thousands of objects to calculate the memory size.

Media makes many allocations, but generally only through a few entry points (VideoFrame, DecoderBuffer). I wonder if something like a tagged allocator would work better than the dump provider mechanism for us.

- dale

--
You received this message because you are subscribed to the Google Groups "media-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to media-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/CAH%3DT95T0ghYu%3DRv7wuQ4yO23UW%2BZrodjrKOzO1EDvf5GMU%2BxVw%40mail.gmail.com.

[Joe Mason]

I think they're contending on locks, actually. For example in PipelineImpl::RendererWrapper::GetStatistics().

Another option that Benoit Lize pointed out this morning, is to just stop running them in background mode. Then the providers can still be run manually during local traces for development, but they won't be included when logging metrics. (I think the interface to view memory dumps in traces is in a bad state right now, but at least the code for these providers will still be there if it's revived.)