[HTTPS-Everywhere] Help needed: Settings window and memory / CPU profiling

Nick Semenkovich nick at semenkovich.com
Wed Jul 1 13:15:28 PDT 2015


On Wed, Jun 17, 2015 at 5:33 PM, Jacob Hoffman-Andrews <jsha at eff.org> 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


More information about the HTTPS-Everywhere mailing list