Last Comment Bug 648784 - (AddonSlowStartup) Addon Slow Startup tests tracking bug
(AddonSlowStartup)
: Addon Slow Startup tests tracking bug
Status: RESOLVED WONTFIX
: meta
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Public Pages (show other bugs)
: unspecified
: All All
: -- normal
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 647398 647561 647954 648113 648222 648225 648229 648732 648734 648737 648742 648745 648749 648751 648752 648793 648978 649286 650709 650710 650778 650790 650947 652497 658187
Blocks: 599169
  Show dependency treegraph
 
Reported: 2011-04-09 14:26 PDT by Nils Maier [:nmaier]
Modified: 2016-02-04 14:51 PST (History)
24 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Nils Maier [:nmaier] 2011-04-09 14:26:37 PDT
Get an overview about what is currently wrong with the Addon Slow Startup tests
Comment 1 Ed Morley [:emorley] 2011-04-09 16:41:58 PDT
Is there a bug for adding items to the best practices list? (https://developer.mozilla.org/en/Extensions/Performance_best_practices_in_extensions)

Would be good to add the suggestion about trying varying XPI compression levels, per: 
http://adblockplus.org/blog/some-more-details-on-mozilla-s-add-on-performance-measurements
(which in the case of ABP made a 15% difference to the addon load time)
Comment 2 Wladimir Palant 2011-04-09 17:04:22 PDT
Generally, the Talk Page is a good place for that. Anyway, I added a section: https://developer.mozilla.org/en/Extensions/Performance_best_practices_in_extensions#Use_the_right_compression_level_for_JAR_and_XPI_files
Comment 3 Ed Morley [:emorley] 2011-04-09 17:11:20 PDT
Yeah I thought as much, I just don't have an MDN login.

Thanks for adding that though :-)
Comment 4 Dave Garrett 2011-04-12 11:21:07 PDT
(In reply to comment #2)
> Generally, the Talk Page is a good place for that. Anyway, I added a section:
> https://developer.mozilla.org/en/Extensions/Performance_best_practices_in_extensions#Use_the_right_compression_level_for_JAR_and_XPI_files

Actually, the last sentence in the first paragraph you added about JARs in XPIs is inaccurate, though not wrong. Using 0 compression (i.e. store instead of deflate) for a JAR inside an XPI will not increase the end XPI file size, it will actually _decrease_ it. It sounds counter-intuitive, but this creates a poor-man's solid archive effect allowing compression between files inside the JAR as apposed to just within files in the XPI. This effect also means that the new trend to ditch the JAR in favor of just an XPI actually increases the XPI file sizes, especially in the case of addons with a large number of locale files that could be better compressed with an internal JAR. I've edited the section slightly to mention this.
Comment 5 Dave Garrett 2011-04-12 11:21:57 PDT
(In reply to comment #2)
> Generally, the Talk Page is a good place for that. Anyway, I added a section:
> https://developer.mozilla.org/en/Extensions/Performance_best_practices_in_extensions#Use_the_right_compression_level_for_JAR_and_XPI_files

Actually, the last sentence in the first paragraph you added about JARs in XPIs is inaccurate, though not wrong. Using 0 compression (i.e. store instead of deflate) for a JAR inside an XPI will not increase the end XPI file size, it will actually _decrease_ it. It sounds counter-intuitive, but this creates a poor-man's solid archive effect allowing compression between files inside the JAR as apposed to just within files in the XPI. This effect also means that the new trend to ditch the JAR in favor of just an XPI actually increases the XPI file sizes, especially in the case of addons with a large number of locale files that could be better compressed with an internal JAR. I've edited the section slightly to mention this.
Comment 6 Dave Garrett 2011-04-12 11:25:51 PDT
Ack, Bugzilla had a server error and said to try again later, but seems to have posted anyway. Sorry for the extra bugspam. :/
Comment 7 Wladimir Palant 2011-04-12 13:09:41 PDT
I know that it decreases XPI size - but that's really irrelevant in that context.
Comment 8 Wil Clouser [:clouserw] 2012-04-09 00:02:43 PDT
The automated perf testing has been on hold for a bit but we're ready to start looking at it again.  I'm working with a new team on what we want to accomplish.  The latest plan is to still alert end users of performance problems but only with manually tested add-ons by someone at Mozilla.  A draft of the plan is at https://wiki.mozilla.org/User:Clouserw/AMO/Perf and I'll be finishing that up this week.

I'm going to wontfix this bug and its friends since they apply to the poor data/policies of v1.  If you've got feedback on the new plan let me know, email the list, talk in #amo, etc.
Comment 9 Wil Clouser [:clouserw] 2012-04-09 00:03:35 PDT
Also should mention - thanks to the folks who filed all these bugs.  I know a lot of research/work went into them.

Note You need to log in before you can comment on or make changes to this bug.