ADR 0013 §9 notes the blocking engine is currently built fresh from the bundled filter-list snapshots at app startup (~150ms parse cost, measured and accepted for the current list set: EasyList + uBO filters/quick-fixes/privacy), with an explicit note to revisit if the list set grows.
If more filter lists get bundled in the future (e.g. additional regional/language lists, or extended cosmetic/procedural selector lists — see #1 for the related CNAME-uncloaking gap), startup parse cost will grow linearly and may eventually be worth trading for a prebuilt/serialized engine blob shipped in the package instead of parsed at runtime.
Not actionable now — current cost (~150ms) is fine. Tracking issue so this doesn't get silently forgotten if the list set changes. See ADR 0013 for the full engine cost/tradeoff writeup.
ADR 0013 §9 notes the blocking engine is currently built fresh from the bundled filter-list snapshots at app startup (~150ms parse cost, measured and accepted for the current list set: EasyList + uBO filters/quick-fixes/privacy), with an explicit note to revisit if the list set grows.
If more filter lists get bundled in the future (e.g. additional regional/language lists, or extended cosmetic/procedural selector lists — see #1 for the related CNAME-uncloaking gap), startup parse cost will grow linearly and may eventually be worth trading for a prebuilt/serialized engine blob shipped in the package instead of parsed at runtime.
Not actionable now — current cost (~150ms) is fine. Tracking issue so this doesn't get silently forgotten if the list set changes. See ADR 0013 for the full engine cost/tradeoff writeup.