New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 887708 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature



Sign in to add a comment

Track size of VideoDecodeStatsDB via UMA

Project Member Reported by chcunningham@chromium.org, Sep 20

Issue description

Its a good idea to set up a UMA to see size in the wild and add some chirp alerts if things change drastically. 

We anticipate the size on disk to be a few dozen KB. Absolute max size could be 22MB (if you played every type of media in every possible framerate and resolution... no one does this). 

This is also gives insight into how much of the shared DB cache we could theoretically use. 
 
Cc: nyquist@chromium.org
nyquist@ - LMK your thoughts on how to approach. I don't want to actually read the whole DB to get this number. Thinking I may just get the stats by looking at the folder on disk. 
Cc: thildebr@chromium.org ssid@chromium.org
+thildebr and +ssid while I'm out.
If the DB folder only contains the DB then I don't see any problem with measuring its size using something like base::ComputeDirectorySize.

When you say how much of the shared DB cache you could theoretically use, you're referring to the shared 8MB block cache? Are you trying to ensure that you're keeping this number low?

Most users of ProtoDatabase end up loading entries from the database once and cache them locally in their de-serialized proto form which means that there's really no use to the read cache at all. If this is the case, it might be worth me adding Get/GetEntry functions that allow custom ReadOptions to avoid filling the read cache at all.

Sign in to add a comment