On Chrome, we're now pretty heavily optimized, see: https://github.com/EFForg/https-everywhere/issues/12
The one remaining issue in Chrome is to use declarativeWebRequest (DWR): https://github.com/EFForg/https-everywhere/issues/132 Unfortunately, DWR is "on hold" in Chrome's beta channel. If we have enough users of Chrome beta/dev/unstable, it might be worthwhile code to add -- though I'm not sure the web store provides usage data segmented by Chrome channel. - Nick On Sun, Dec 28, 2014 at 9:23 AM, Alex Xu <[email protected]> wrote: > On 27/12/14 06:18 PM, Jacob Hoffman-Andrews wrote: >> This is an interesting analysis of how much CPU and memory AdBlock Plus >> consumes, finding it to be rather high. It would be great to do a similar >> analysis on HTTPS Everywhere, see we do similar things and probably have >> similar performance issues. >> >> https://github.com/gorhill/uBlock/wiki/%C2%B5Block-vs.-ABP:-efficiency-compared >> _______________________________________________ >> HTTPS-Everywhere mailing list >> [email protected] >> https://lists.eff.org/mailman/listinfo/https-everywhere >> > > HTTPS-Everywhere does not load any CSS in content pages, as that is > entirely irrelevant to its purpose. > > CPU overhead I believe to be negligible, especially considering that > HTTPS-E rules use a basic domain matching mechanism before considering > regular expressions. > > Memory overhead is significant, but has been reduced recently due to the > introduction of the internal SQLite database. > > > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere -- 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
