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. _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
