On 10/13/14 5:09 PM, Kyle Huey wrote:
On Mon, Oct 13, 2014 at 4:54 PM, Chris More <cm...@mozilla.com> wrote:
Does anyone know or could any of you create a breakdown of the major blocks of
the Firefox installer and each of their respective sizes or percentage of the
whole?
For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth
team [1] like to know of that 34MB, what is the percentage or size of each of
the components within the 34MB. As for the granularity of the breakdown, it
would be by some logic way of breaking down Firefox. For example, SpiderMonkey,
tools, XUL, etc. I'll leave the granularity up to you on what you consider a
logic block to quantify together.
Why am I asking this?
The win32 Firefox full installer continues to grow (see attachment) each
release and it has been on an increasing growth since Firefox 29. Like anything
on the web, the time it takes to download something (webpage, binary file,
etc.) affects the key conversion rate by some amount. The Firefox Growth team
has a project to understand what features/changes in Firefox are contributing
to the growth or size of the installer. We've asked a few times previously, but
it doesn't look like the documentation or analysis exist.
Would anyone be able to take on this project as it would be very helpful to the
team? I am imagining a pie chart of the the current installer and then a table
of the name of each component, their size (KB or MB), and any additional meta
data.
Thanks,
Chris
[1] https://wiki.mozilla.org/Growth_Team
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
The simplest way to break the installer down is by the files in it.
e.g. http://khuey.pastebin.mozilla.org/6781501
File boundaries are a reasonably logical division to start with. Once
you've identified which files are growing/being added over time we can
explain what those are and where the growth comes from (in terms of
features/etc).
- Kyle
one thing to add on Kyle's analysis and numbers is to zip all the files
back up individually, then measure the size of each, since text files
are likely to have a higher compression rate than binary.
You also need to separate the analysis and reporting into two problems.
This one time process that you are doing to figure out where things are
is good, but its not the way to make continuous improvement.
To make continuous improvement and avoid future regression the build and
automated testing process needs to record these numbers, then flag and
create a failed test when a components size grows beyond a threshold.
That enforces review when the growth happens and conscious decisions
about the trade off of functionality v. size growth and loss of users in
the download and installation steps.
Probably need to file a bug on this continuous monitoring and testing
and get it assigned for someone to take action. Otherwise we will still
be having the conversation a year from now and the still will have
continued on with another year of growth.
Here are the conversations from two years ago " Firefox download size -
2012"
https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/k7fzkhdt9io
and from last year " Firefox installer size: How big is too big? - 2013"
https://groups.google.com/forum/#!searchin/mozilla.dev.planning/installer$20size/mozilla.dev.planning/hPgUBzweL70/NeOjEf0hsh0J
Now that we have a strategy for putting developer tools in there own
release I'd guess the biggest immediate win is to yank the developer
tools from the "consumer version", and maybe make them available as an
addon. Is there bug open on that and is that part of the upcoming plan?
-chofmann
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
