New issue
Advanced search Search tips

Issue 778056 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

Extension: verified_contents.json and computed_hashes.json are parsed ~100 times.

Project Member Reported by erikc...@chromium.org, Oct 25 2017

Issue description

Repro steps:

win7 [may also work on other machines, didn't check].

1) Start Chrome ToT with a new profile. 
2) Install LastPass https://chrome.google.com/webstore/detail/lastpass-free-password-ma/hdokiejnpimakedhajhdlcegeplioahd?hl=en-US. 
3) Restart Chrome
4) Hit the LastPass extension icon.

On both startup [3] and hitting the extension icon [4], both JSOn files are read from disk and parsed about ~50 times. This has significant performance overhead. 
 
well, that's not good.  This is likely because we verify files as they're requested by the extension.  Now, the fact that last pass is requesting 50 files when hitting the extension icon is also bad (and probably something we should figure out why).  But it'd be awfully nice to avoid hitting hashes and verified contents each time.

lazyboy@, do we have metrics on what the average size of these files is?  How terrible would it be to just store them in memory?
Labels: -Performance Performance-Browser
I've looked into this issue. On clicking the browser action, there are *43 extension resources* that are requested from lastpass, each of them will contribute to one read of computed_hashes and verified_contents, that aligns with the observation of comment #0. Similar load happens during startup.


@comment #1 re size:
I don't know of any particular metrics we have, but I don't think it's going to be cheap to cache in a straightforward manner.

verified_contents.json: depends on # of files the extension has and the average length of each resource's relative path name. e.g. Lastpass has over 1400 files, making verified_contents.json ~190k
computed_hashes.json: this would be at least the size of verified_contents.json, and then this file depends on the size of individual file, adding roughly 43 bytes per 4k file content. For lastpass this is 319k


To give a picture of less extreme extension, grammarly has
37 files
verified_contents.json: 5.5k
computed_hashes.json: 122k

Given the sizes of this files, I'd think caching them during the entirety of extension's lifetime might not be the best idea, maybe we can keep last X extension's data in the cache? Or something similar.
Using an LRU cache seems like a relatively simple approach that will get most of the desired benefit [preventing rapid reparsing of JSON files] with relatively low memory impact. Will there will synchronization issues, since right now it looks like tasks get sharded across 16 different task queues? May need/want to create a task-queue affinity for these verification tasks.

... Anyhow, I'm sure you know more details. :)

Sign in to add a comment