Closed
Bug 753437
Opened 13 years ago
Closed 13 years ago
increase in browser start times with a couple of well known extensions
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 726125
People
(Reporter: danialhorton, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120509030514
Steps to reproduce:
Created a new profile
Installed Ebay Sidebar
Installed Element Hiding helper for ABP
(And i will post more to comments as i find them)
Actual results:
3-5 seconds before the window appeared
Expected results:
Instant appearance
This seems to be a regression, i remember using these extensions back when the startupcache and packed xpi's were implemented and startup was almost instant.
Reporter | ||
Comment 1•13 years ago
|
||
9 seconds with Sidebar + Element hiding helper
5 seconds with element hiding helper only
2 seconds without both
im positive theres 1 more i haven't found yet.
Reporter | ||
Comment 2•13 years ago
|
||
without ABP the window appears within a second
so this must mean theres one more then.
(i already checked this combination with all addons disabled and installed to a new profile btw)
Reporter | ||
Comment 3•13 years ago
|
||
unpacked all 3 directly into the extensions folder and startup is 3s
have you started using compression on your xpi's Wladamir?
Reporter | ||
Comment 4•13 years ago
|
||
never mind, even a compression setting of 0 (store only) doesn't improve the speed
as long as these 3 extensions are packed, startup time is hit.
Has anything possibly landed that impacts the performance of packed extensions?
Comment 5•13 years ago
|
||
So, are you testing with Element Hiding Helper only or in combination with Adblock Plus? I just tried running the current nightly via Talos, the impact of EHH on startup time is non-existent.
Without EHH:
i,val
0,1618
1,1463
2,1447
3,1463
4,1440
RETURN: ts: 1453.25
With EHH:
i,val
0,1629
1,1457
2,1437
3,1459
4,1462
RETURN: ts: 1453.75
Adblock Plus on the other hand has an impact on statup time of course - but that strongly depends on configuration.
Reporter | ||
Comment 6•13 years ago
|
||
only had ebay/element hider in the new profile at first, but i can take abp's hit there, its only 1 second at best with only it enabled
What i would like to know is why unpacking these 3 extensions from their xpi's decreases the amount of time it takes for the browser window to finally apear from 9 seconds to 2-3 seconds
Its stalling at the prestart stuff in any case, i already checked process mon and its not a matter of configuration, the settings are only loaded as the window starts to appear
Reporter | ||
Comment 7•13 years ago
|
||
theres still a delay of about 3 seconds with them all in a clean profile in packed xpi's.
Wladamir, this wasn't specifically targetting the extensions functionality, something does seem to have affected the loading of xpi files during browser start which us reduced by leaving larger extensions unpacked.
the more packed xpi's you have, the more you will see it. though so far i've only found that extensions that are over 1.5MB when completely unpacked are improving start times when unpacked.
This delay period is during the startup phase, prior to actually executing the extensions functionality so its likely not an extension coding issue.
Reporter | ||
Comment 8•13 years ago
|
||
has anyone investigated this at all, its still reproducible in nightly 17, same resolution still works too (unpacking the extension).
Updated•13 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•