On 01/12/2014 04:34 PM, Claudio Moretti wrote:
how does the schema handle duplicate targets?
The schema works fine with duplicate targets, but as you point out, the
JS code I wrote ignores the possibility of multiple results. The
validator complains about duplicate entries, so I wasn't sure what
behavior to implement here. I've changed it to include the duplicate
entries.
On 01/12/2014 01:23 PM, Vijay P wrote:
You could start a webworker to copy everything from the DB to RAM in
the background when you start up...
I didn't have time to learn about webworkers and add the code. Instead I
added a compromise: At startup we load just the list of available
targets, so we only have to hit the DB when we know there is a target
match. This speeds up browsing significantly and only costs ~300 ms at
startup on my 6-year old laptop. This also helps keep the initial memory
footprint down (411k vs 3.4M), and most of the rulesets never need to be
parsed since they are never visited.
If you're interested in writing a webwork to eliminate that remaining
300ms delay, I would be interested in that!
Also, it appears that HTTPSRules.init gets called three times during
startup, which amplifies the slowness:
https://github.com/EFForg/https-everywhere/issues/84.
New version at
https://jacob.hoffman-andrews.com/hacks/https-everywhere-jsha-sqlite-demo-v2.xpi
(.asc for sig).
_______________________________________________
HTTPS-Everywhere mailing list
[email protected]
https://lists.eff.org/mailman/listinfo/https-everywhere
