Closed Bug 1162392 Opened 9 years ago Closed 6 years ago

Sorting by hits in a filterlist in ABP takes twice as long with compartment per addon

Categories

(Firefox :: Extension Compatibility, defect, P5)

Product:
Firefox
Component:
Extension Compatibility
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: elbart, Unassigned)

References

(Blocks 1 open bug)

Details

+++ This bug was initially created as a clone of Bug #1153387 +++

Recent Nightly
Recent ABP-dev build
EasyList filterlist

With e10s off, sorting in the EasyList filterlist by hits takes twice as long with dom.compartment_per_addon;true than with false., regardless of e10s being enabled or not.

Benchmark on my machine, Nightly:
dom.compartment_per_addon true : 5s
dom.compartment_per_addon false:  3s

comparison: 
Firefox 24.8.1 with ABP 2.6.6: 3s
Firefox 31.6.1 with ABP 2.6.9: 3s


Regression-ranges:
Last good revision: 1e2993c99323 (2014-09-24)
First bad revision: 1735ff2bb23e (2014-09-25)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1e2993c99323&tochange=1735ff2bb23e
	35dcddea2c7a	Bill McCloskey — Bug 1030420 - Enable compartment-per-addon on Nightly. r=bholley
Blocks: abp, 1030420
Summary: Sorting by hits in a filterlist in ABP takes three times as long with shims → Sorting by hits in a filterlist in ABP takes twice as long with compartment per addon
Although shim-performance is now matching shim-less performance (bug 1164014), the slowdown from compartment-per-addon still occurs.

AFAIK compartment-per-addon is for e10s, so I'm adding that tracking bug.
Blocks: e10s-perf
Priority: -- → P5
Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.

Sorry for the bug spam, and happy Friday!
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.