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)

x86_64
Windows 7
defect
Not set
normal

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.
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.
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)
unpacked all 3 directly into the extensions folder and startup is 3s have you started using compression on your xpi's Wladamir?
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?
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.
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
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.
has anyone investigated this at all, its still reproducible in nightly 17, same resolution still works too (unpacking the extension).
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.