On Fri, Jan 17, 2014 at 08:01:40PM -0800, Mike Perry wrote: > > > We should measure this. But we should definitely measure it in the case > > where the entire sqlite file is in the OS page cache, so in TBB we > > should /definitely/ read and discard its entire contents before playing. > > Yes. Having solid numbers here would make me feel better about this. >
So I have implemented some performance tests in the sqlite branch of my github remote: https://github.com/pde/https-everywhere/commits/sqlite They operate by asking potentiallyApplicableRulesets() for each of the Alexa top 10K domains, measuring overall ellapsed time, then doing it again. Here's what I see: Calling potentiallyApplicableRulesets() with 10000 domains 1088 hits: average call to potentiallyApplicableRulesets took 0.157 milliseconds 1088 hits: average subsequent call to potentiallyApplicableRulesets took 0.0513 milliseconds So wrt Mike's fingerprinting concern, subsequent calls to potentiallyApplicableRulesets() are 3x faster (and will be more so if we put in the LRU cache) but the measurable difference is only a tenth of a millisecond, which will be hard to exploit given that this is over the top of the Tor network and repetitive measurement is impossible. Along the way I noticed the very weird phenomenon that unless I prepend "www." to the test domains I only get a handful of hits, more like 20 than 1088. This makes me think that either there are lots and lots of rulesets that target *.example.com and not example.com, or there's a bug in the sqlite patch somewhere... -- Peter Eckersley [email protected] Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
