Assigning to Michael, as he is exploring quota manager stuff. Michael, I think good metrics here can be done around deleting for each quota type - we don't initially need to specialize w/ what the filter is doing. So maybe:

* Time until deletion completes, split by quota system type
* The number of origins effected by deletion, by quota system type

WDYT?

Looking at the original bug, I think the place to start is probably timing the various subtasks of BrowsingDataRemoverImpl, one of which is clearing the StoragePartition data one of which is Quota managed stuff. There are these levels...

BrowsingDataRemoverImpl::SubTask
  SubTask synchronous_clear_operations_;
  SubTask clear_embedder_data_;
  SubTask clear_cache_;
  SubTask clear_channel_ids_;
  SubTask clear_http_auth_cache_;
  SubTask clear_storage_partition_data_;

StoragePartition::DataDeletionHelper + QuotaManagedDataDeletionHelper
    // not quota managed
    REMOVE_DATA_MASK_COOKIES = 1 << 1,
    REMOVE_DATA_MASK_LOCAL_STORAGE = 1 << 4,
    REMOVE_DATA_MASK_SHADER_CACHE = 1 << 5,
    REMOVE_DATA_MASK_PLUGIN_PRIVATE_DATA = 1 << 9,
    // quota managed
     (remove_mask & REMOVE_DATA_MASK_INDEXEDDB ||
      remove_mask & REMOVE_DATA_MASK_WEBSQL ||
      remove_mask & REMOVE_DATA_MASK_APPCACHE ||
      remove_mask & REMOVE_DATA_MASK_FILE_SYSTEMS ||
      remove_mask & REMOVE_DATA_MASK_SERVICE_WORKERS ||
      remove_mask & REMOVE_DATA_MASK_CACHE_STORAGE)

QuotaManager::GetOriginsModifiedSince + OriginDataDeleter
    IDB, ServiceWorker...

My guess is cookies and cache play a significant role.

Yeah - I'd love to split it up per storage type. I don't know if it'll be easy to detect if the 'filter' is a single origin or all, but I imagine this would produce an easy bi-modal histogram that we could tell which is which.