On Wed, Jun 17, 2015 at 5:33 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
*snip* > Beyond the settings window problem, HTTPS Everywhere just consumes too much > memory. We should approach this in a disciplined way: Pick a set of 100 sites > and run a memory profile of HTTPS Everywhere as it loads them, then attack > the largest sources of memory use first. We should probably also do CPU > profiling, as there are big wins to be had there. This is an issue across > both Firefox and Chrome, but I think Firefox has a bigger problem, since Nick > Semenkovich has already done a lot of great work on speeding up the Chrome > extension. Unfortunately I don't have any experience profiling Firefox > extensions, so we need someone who either has that experience or wants to put > in the time to learn it. > Thanks for the shout out! One tractable issue for Chrome is to reduce unnecessary interception of HTTPS requests. We listen to all HTTPS requests (e.g. to fix certificate name errors). That's a bit slow (from native code -> our blocking javascript handlers -> back to native code). See: https://github.com/EFForg/https-everywhere/issues/1327 We can clean up this request path by only listening to the few HTTPS sites where rulesets could potentially apply. i.e. Instead of listening to https://*/*, just listen to *.va.gov when we want to redirect https://something.va.gov -> https://somethingelse.va.gov This'll take a bit of clever wildcarding/rule tweaks -- about ~15 rules have wildcards in the middle of them -- which Chrome disallows (see: https://developer.chrome.com/extensions/match_patterns) -- Nick Semenkovich Laboratory of Dr. Jeffrey I. Gordon Medical Scientist Training Program School of Medicine Washington University in St. Louis https://nick.semenkovich.com _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
