@jsha for review, unless anyone else wants to look at the chrome code :)

I definitely like the simplification. It's interesting that Map.prototype.keys() returns keys in insertion order rather than random or alphabetically. I didn't know that! It's probably worth commenting about it on the line where you remove.

You said it seems to be more performant. Is that based on performance testing, or general feel? If the former, can you share your methodology?

Thanks for the review! Making those changes and will rebase after you merge #3961 since they'll conflict on a line or two.

Alas, performant is based on a squishy "pseudo-testing" with Chrome's Javascript CPU profiler while opening sets of tabs (in a fresh profile) and observing the % cpu & timing info.

I'd love a better way to do this programmatically, or in Travis -- any thoughts?

Another question: I think this is the first hard dependency on ECMA2015 in the Chrome code, right?

I would like, at some point not too far off, to move the rules code into a shared directory, and migrate the Firefox extension to it, so we can get the benefit of these recent performance improvements (and generally cleaner code). We need to support Firefox ESR for the purposes of the Tor browser, and well as Firefox latest. If you could investigate whether Map() and similar ECMA2015 features are available in ESR, I'd greatly appreciate it. If they're not, I'd prefer to use other functionality where possible.

Yep -- this is the first hard ES6 dependency, and it's compatible with FF38 ESR, per: https://kangax.github.io/compat-table/es6/

I commented a bit in #2640 too -- I'm trying to clean the Chrome implementation and stick to APIs (unrelated to this PR) that are supported by FF's new WebExtension model.

LGTM. Needs merge.

Merging per above LGTM.

This broke rewriter that is used by us for various tests.

Cool -- any thoughts on fixing it? (I'm not that familiar with how it works -- though it looks like you could just rip out the lrucache reference.)

@semenko Looks like pretty much that's it (plus fix RuleSets constructor - with new approach it should receive smth like Object.create(null) by default?). This fix should be easy, but more generally, as mentioned in that comment, would be nice to have separate parts of HTTPS Everywhere decoupled so that they could be used and updated independently without future code breakages. Do you think that would be possible?

Yeah, it's definitely something good to do, though we'll need think about the best way to do it while preserving git history, etc.

@semenko Git history can be rewritten AFAIK - e.g. you can see entire UNIX history converted to Git few days ago https://github.com/dspinellis/unix-history-repo/commits/master?page=3951