On 11/29/13, 5:12 AM, Ehsan Akhgari wrote:
On 11/28/2013, 4:55 PM, Mike Hoye wrote:
On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying "if you're paid to work by
Mozilla, get a faster machine". More generally, we're all in furious
agreement: fast builds are good; achieving them via multiple means is
worthwhile; those with the option of getting faster hardware should do
so.
That's all true, but if we end up in a place where a box with "only" 2GB
of RAM can't build Firefox at all that will be a serious problem, and a
major barrier to community participation. I get that this can't be true
for phones, sure, but "official support" for Firefox shouldn't just mean
"you can run Firefox on this platform", it should as often as possible
also mean "you can build Firefox on this platform."
We won't get there, at least not any time soon. Which is why I'm asking
people to file bugs if the unified build stuff has caused that
limitation to appear. Hardware that could build our code two weeks ago
should not be considered as "inadequate" because of my work here, that's
all I'm saying. :-)
People with less than 8 GB RAM have likely had issues building Firefox
for years. Linking libxul is in particular very painful. Depending on
the platform, you have to page in up to a few GB of object files. On top
of that, the linker allocates a few GB. About a year ago, I calculated
that you needed 9-10 GB available memory to build on Linux without
incurring any disk I/O. If you had any less than that and were on a
mechanical disk, your build times were a minute or two slower.
What unified sources has done is increased memory consumption during
compilation thus increasing the risk of swapping there. Previously,
swapping was most likely during linking libxul.
What I meant in my previous reply was that I'm concerned about users
with modern machines being handicapped by the needs of those with slower
machines. e.g. if we have to decrease the number of sources going into
each unified source to reduce memory and this change makes builds 6
minutes instead of 5 minutes for a modern machine with tons of RAM,
that's not cool. I would much rather we explore different build modes
for people with different hardware configurations. e.g. decrease
concurrency on machines with insufficient memory. The build system can
also be much more proactive about suggesting faster build configurations
(e.g. use Clang over GCC, use a more modern compiler, disable debug
symbols, use gold, etc). Unfortunately, we have practically zero insight
into what people are using in the wild, so it's difficult to target pain
points and to measure the impact of various changes. This is why I want
reporting of build stats to Mozilla. Maybe in Q1.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
