1.9.8

Changes

Core code related to static and cosmetic engines has been refactored to take advantage of ES6 Set/Map (related issue: #1070). Polyfilled versions of Set/Map are provided for compatibility with Chromium 37 and less^[1], and for Pale Moon 26 and earlier^[2]. While at it, I also revisited some of the inner-most loops executed at load time to remove other observed overheads in profiling results.

Benchmarks shows that there are good gains to be had in performance and memory efficiency when using ES6 Set/Map. The performance gains are especially true when dealing with collections with a lot of misses, which is typical of the static and cosmetic filtering engines ni uBO.

Following the above refactoring, profiling Chromium/Firefox, I observed:

• Non-selfie case: uBO will roughly load in about half the time, because:
  • Using ES6 Set and Map instead of Object
  • No longer using String.split to split lines into fields = less memory allocations = less work for garbage collector
• Selfie-case: there is a marginal performance improvement at most in boot time -- make sense since a selfie is just a no-parsing-at-all load mechanism regardless of how the data is represented internally.

_{Chromium + uBO with default settings + EasyList Germany -- forgot to un-check it before profiling...}

_{Nightly + uBO with default settings}

Closed as fixed:

Chromium

• Local file:// filter lists not loading in Chromium browsers

Core

• Automatically lookup site-specific scriptlets
• How to disable script:inject filters?
• Popups with data:text/html... URL can't be blocked

---

1. When the polyfilled Set/Map are used for Chromium-based browsers, uBO's memory usage will be higher, as using Object as Set or Map is less efficient memory-wise (though still fast).
2. For Pale Moon 26 and less, Set/Map iterators are not ES6-compatible.