[HTTPS-Everywhere] Startup time measurements in Chrome and Firefox

[Jacob Hoffman-Andrews]

On 01/17/2014 06:37 PM, Mike Perry wrote:
> In TBB, we isolate the browser cache per the URL bar domain

Nice! I learn something new every day.

We could have a 'paranoid mode' for TBB that uses a webworker
on startup to preload all the rules, removing the timing oracle.

Though your 0.06 seconds to just load the whole JSON version is
also pretty compelling.

> How fast are these individual queries? Can we measure that, and what the impact is on total
> page performance for the cache hit and non-cache hit cases?

Good question. I see you and Peter are adding measurement: thanks!

> I am especially worried about the sync SQLLite lookups as well, as you point out that may make
> people perceive the actual browser UI to get sluggish during page load, which is not good
> either.

The sqlite APIs do offer an async version, but I haven't found a way to
go async and still be able to rewrite the request - do you know of anything
like that?

On 01/17/2014 06:41 PM, Peter Eckersley wrote:
> whole .sqlite file is in the OS'es page cache; it looks like it takes up about 20MB.

I see 5.7M for the uncompressed version on disk.

> Another downside is that the .sqlite file format roughly doubles the size of our .xpi file from
> ~1MB to ~2MB (in the current master branch). I guess we can live with that.  We should warn
> EFF's ops team though :).

I poked at this a little: .5M of that is the index on `target' which is actually
not necessary for performance: when preloading the targets we can also save
the ruleset_id to lookup later.

We can get another .1M by snipping <target> tags from the stored XML.