Re: Deciding whether to change the number of unified sources

[L. David Baron]

On Wednesday 2013-12-04 16:36 -0500, Ehsan Akhgari wrote:
> On Tue, Dec 3, 2013 at 2:47 PM, L. David Baron  wrote:
> > I'd certainly hope that nearly all of the difference in size of
> > libxul.so is debugging info that wouldn't be present in a non-debug
> > build.  But it's worth testing, because if that's not the case,
> > there are some serious improvements that could be made in the C/C++
> > toolchain...
> 
> Well, not really.  In the case of unified builds, the compiler sees larger
> translation units, so it has better opportunity for optimizations such as
> inlining, DCE, etc.

I did a set of builds on changeset 8648aa476eef, on 64-bit Linux
with gcc, to test these theories.

 Neither -DDEBUG-DDEBUG  optimized
  nor optimized

The sizes I get from the build (with -g) are:
Nonunified 834700176  905487728  907369496
Unified520194760  563257880  55484

If I run "strip --strip-debug" on these, this removes the vast
majority of the size difference:
Nonunified 155896907  176296907   87984550
Unified152048885  168215761   87616359

And if I further run "strip" on these, I get:
Nonunified 111273928  128967104   65150320
Unified109413312  123112424   64863456

readelf -WS (on the "optimized" pair) showed size differences in
many of the sections, but the largest differences were the .debug_*
ones.

So indeed, *most* of the size difference is debugging info.  But
there is indeed still a small size difference without the debugging
info (about 0.5% for optimized and not -DDEBUG, more without
optimization or with -DDEBUG).

(I still have all of the above binaries if people are interested in
more information from them.)

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ehsan Akhgari]

On Tue, Dec 3, 2013 at 2:47 PM, L. David Baron  wrote:

> On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> > Also, I would be very interested in seeing "size of libxul.so" for
> > fully-optimized (including PGO, where we normally do PGO) builds. Do
> > unified builds help or hurt libxul size for release builds? Do unified
> > builds help or hurt performance in release builds?
>
> I'd certainly hope that nearly all of the difference in size of
> libxul.so is debugging info that wouldn't be present in a non-debug
> build.  But it's worth testing, because if that's not the case,
> there are some serious improvements that could be made in the C/C++
> toolchain...


Well, not really.  In the case of unified builds, the compiler sees larger
translation units, so it has better opportunity for optimizations such as
inlining, DCE, etc.

--
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Chris Peterson]

On 12/3/13, 2:48 PM, Mike Hommey wrote:

>I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw
>no significant difference (up or down) in real time compared to 16
>files. This result is in line with Mike's results showing only small
>improvements between 8, 12, and 16 files.

Did you also fix the build failures? Because with 100, I got some but
didn't try to fix them.


I fixed some build failures locally, but I usually just moved the broken 
file from UNIFIED_SOURCES to SOURCES because I was only testing whether 
there was any difference.


chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Mike Hommey]

On Tue, Dec 03, 2013 at 01:30:39PM -0800, Jed Davis wrote:
> On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote:
> > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> > > Also, I would be very interested in seeing "size of libxul.so" for
> > > fully-optimized (including PGO, where we normally do PGO) builds. Do
> > > unified builds help or hurt libxul size for release builds? Do unified
> > > builds help or hurt performance in release builds?
> > 
> > I'd certainly hope that nearly all of the difference in size of
> > libxul.so is debugging info that wouldn't be present in a non-debug
> > build.  But it's worth testing, because if that's not the case,
> > there are some serious improvements that could be made in the C/C++
> > toolchain...
> 
> At the risk of stating the obvious, localizing the size change should
> be a simple matter of `readelf -WS`.  If we're seeing actual change
> in .text size by way of per-directory sort-of-LTO, then that would be
> interesting (and could be localized further with the symbol table).

Or using size, which I did, but didn't paste and I don't have the data
anymore. IIRC, size tends to be smaller with higher number of unified
sources, but not by a big margin.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Mike Hommey]

On Tue, Dec 03, 2013 at 10:20:20AM -0800, Chris Peterson wrote:
> On 12/3/13, 8:53 AM, Ted Mielczarek wrote:
> >On 12/2/2013 11:39 PM, Mike Hommey wrote:
> >>Current setup (16):
> >>   real11m7.986s
> >>   user63m48.075s
> >>   sys 3m24.677s
> >>   Size of the objdir: 3.4GiB
> >>   Size of libxul.so: 455MB
> >>
> >Just out of curiosity, did you try with greater than 16?
> 
> I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw
> no significant difference (up or down) in real time compared to 16
> files. This result is in line with Mike's results showing only small
> improvements between 8, 12, and 16 files.

Did you also fix the build failures? Because with 100, I got some but
didn't try to fix them.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Gabriele Svelto]

On 03/12/2013 22:30, Jed Davis wrote:

At the risk of stating the obvious, localizing the size change should
be a simple matter of `readelf -WS`.  If we're seeing actual change
in .text size by way of per-directory sort-of-LTO, then that would be
interesting (and could be localized further with the symbol table).


It would be interesting to see if this had an impact on our performance 
profile too.


 Gabriele

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Jed Davis]

On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote:
> On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> > Also, I would be very interested in seeing "size of libxul.so" for
> > fully-optimized (including PGO, where we normally do PGO) builds. Do
> > unified builds help or hurt libxul size for release builds? Do unified
> > builds help or hurt performance in release builds?
> 
> I'd certainly hope that nearly all of the difference in size of
> libxul.so is debugging info that wouldn't be present in a non-debug
> build.  But it's worth testing, because if that's not the case,
> there are some serious improvements that could be made in the C/C++
> toolchain...

At the risk of stating the obvious, localizing the size change should
be a simple matter of `readelf -WS`.  If we're seeing actual change
in .text size by way of per-directory sort-of-LTO, then that would be
interesting (and could be localized further with the symbol table).

--Jed

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Benoit Jacob]

Here, stripping a non-opt debug linux 64bit libxul brings it down from 534
MB down to 117 MB.

Benoit


2013/12/3 L. David Baron 

> On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> > Also, I would be very interested in seeing "size of libxul.so" for
> > fully-optimized (including PGO, where we normally do PGO) builds. Do
> > unified builds help or hurt libxul size for release builds? Do unified
> > builds help or hurt performance in release builds?
>
> I'd certainly hope that nearly all of the difference in size of
> libxul.so is debugging info that wouldn't be present in a non-debug
> build.  But it's worth testing, because if that's not the case,
> there are some serious improvements that could be made in the C/C++
> toolchain...
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[L. David Baron]

On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> Also, I would be very interested in seeing "size of libxul.so" for
> fully-optimized (including PGO, where we normally do PGO) builds. Do
> unified builds help or hurt libxul size for release builds? Do unified
> builds help or hurt performance in release builds?

I'd certainly hope that nearly all of the difference in size of
libxul.so is debugging info that wouldn't be present in a non-debug
build.  But it's worth testing, because if that's not the case,
there are some serious improvements that could be made in the C/C++
toolchain...

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ehsan Akhgari]

On 12/3/2013, 2:08 PM, Benoit Jacob wrote:

2013/12/3 Chris Peterson 


On 12/3/13, 8:53 AM, Ted Mielczarek wrote:


On 12/2/2013 11:39 PM, Mike Hommey wrote:


Current setup (16):
real11m7.986s
user63m48.075s
sys 3m24.677s
Size of the objdir: 3.4GiB
Size of libxul.so: 455MB

  Just out of curiosity, did you try with greater than 16?




I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw no
significant difference (up or down) in real time compared to 16 files. This
result is in line with Mike's results showing only small improvements
between 8, 12, and 16 files.



See my email earlier in this thread.  Until we know the effective
unification ratio (as opposed to the one we request) we can't draw
conclusions from that.


Yeah, that's true.  If you're curious, you can instrument this code: 
 
recording the number of items in iterable and the number of tuples that 
it returns, and then add the numbers up across the tree and do 
interesting things with it.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ehsan Akhgari]

On 12/3/2013, 1:18 PM, Brian Smith wrote:

On Tue, Dec 3, 2013 at 8:53 AM, Ted Mielczarek  wrote:

On 12/2/2013 11:39 PM, Mike Hommey wrote:

Current setup (16):
   real11m7.986s
   user63m48.075s
   sys 3m24.677s
   Size of the objdir: 3.4GiB
   Size of libxul.so: 455MB


Just out of curiosity, did you try with greater than 16?


This is what I want to know too, because based on your numbers, it
looks like 16 is the best of those listed.


I would expect the exact same trend to continue, as in, all three 
numbers getting smaller, and the compiler memory usage continuing to 
rise.  I would also expect the rate of improvements to keep diminishing 
as we move to larger values.



Also, I would be very interested in seeing "size of libxul.so" for
fully-optimized (including PGO, where we normally do PGO) builds. Do
unified builds help or hurt libxul size for release builds? Do unified
builds help or hurt performance in release builds?


It make sense for both of those metrics to improve a little bit at least 
for non-PGOed code, but the differences are probably very minor.


Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Benoit Jacob]

2013/12/3 Chris Peterson 

> On 12/3/13, 8:53 AM, Ted Mielczarek wrote:
>
>> On 12/2/2013 11:39 PM, Mike Hommey wrote:
>>
>>> Current setup (16):
>>>real11m7.986s
>>>user63m48.075s
>>>sys 3m24.677s
>>>Size of the objdir: 3.4GiB
>>>Size of libxul.so: 455MB
>>>
>>>  Just out of curiosity, did you try with greater than 16?
>>
>
> I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw no
> significant difference (up or down) in real time compared to 16 files. This
> result is in line with Mike's results showing only small improvements
> between 8, 12, and 16 files.
>

See my email earlier in this thread.  Until we know the effective
unification ratio (as opposed to the one we request) we can't draw
conclusions from that.

Benoit



>
> chris
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Chris Peterson]

On 12/3/13, 8:53 AM, Ted Mielczarek wrote:

On 12/2/2013 11:39 PM, Mike Hommey wrote:

Current setup (16):
   real11m7.986s
   user63m48.075s
   sys 3m24.677s
   Size of the objdir: 3.4GiB
   Size of libxul.so: 455MB


Just out of curiosity, did you try with greater than 16?


I tested unifying 99 files. On my not-super-fast MacBook Pro, I saw no 
significant difference (up or down) in real time compared to 16 files. 
This result is in line with Mike's results showing only small 
improvements between 8, 12, and 16 files.



chris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Brian Smith]

On Tue, Dec 3, 2013 at 8:53 AM, Ted Mielczarek  wrote:
> On 12/2/2013 11:39 PM, Mike Hommey wrote:
>> Current setup (16):
>>   real11m7.986s
>>   user63m48.075s
>>   sys 3m24.677s
>>   Size of the objdir: 3.4GiB
>>   Size of libxul.so: 455MB
>>
> Just out of curiosity, did you try with greater than 16?

This is what I want to know too, because based on your numbers, it
looks like 16 is the best of those listed.

Also, I would be very interested in seeing "size of libxul.so" for
fully-optimized (including PGO, where we normally do PGO) builds. Do
unified builds help or hurt libxul size for release builds? Do unified
builds help or hurt performance in release builds?

Cheers,
Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Benoit Jacob]

I would like to know the *effective* average number of original source
files per unified source file, and see how it compares to the *requested*
one (which you are adjusting here).

Because many unified directories have a low number of source files, the
effective number of sources per unified source will be lower than the
requested one.

Benoit


2013/12/2 Mike Hommey 

> Hi,
>
> It was already mentioned that unified builds might be causing memory
> issues. Since the number of unified sources (16) was decided more or
> less arbitrarily (in fact, it's just using whatever was used for
> ipdl/webidl builds, which, in turn just used whatever seemed a good
> tradeoff between clobber build and incremental build with a single .cpp
> changing), it would be good to make an informed decision about the
> number of unified sources.
>
> So, now that mozilla-inbound (finally) builds with different numbers of
> unified sources (after fixing bugs 944844 and 945563, but how long
> before another problem slips in?[1]), I got some build time numbers on my
> machine (linux, old i7, 16GB RAM) to give some perspective:
>
> Current setup (16):
>   real11m7.986s
>   user63m48.075s
>   sys 3m24.677s
>   Size of the objdir: 3.4GiB
>   Size of libxul.so: 455MB
>
> 12 unified sources (requires additional patches for yet-to-be-filed bugs
> (yes, plural)):
>   real  11m18.572s
>   user  65m24.145s
>   sys   3m28.113s
>   Size of the objdir: 3.5GiB
>   Size of libxul.so: 464MB
>
> 8 unified sources:
>   real11m47.825s
>   user68m21.888s
>   sys 3m39.406s
>   Size of the objdir: 3.6GiB
>   Size of libxul.so: 476MB
>
> 4 unified sources:
>   real  12m52.630s
>   user  76m41.208s
>   sys   4m2.783s
>   Size of the objdir: 3.9GiB
>   Size of libxul.so: 509MB
>
> 2 unified sources:
>   real  14m59.050s
>   user  90m44.928s
>   sys   4m45.418s
>   Size of the objdir: 4.3GiB
>   Size of libxul.so: 561MB
>
> disabled unified sources:
>   real  18m1.001s
>   user  113m0.524s
>   sys   5m57.970s
>   Size of the objdir: 4.9GiB
>   Size of libxul.so: 628MB
>
> Mike
>
> 1. By the way, those type of bugs that show up at different number of
> unified sources are existing type of problems waiting to arise when we
> add source files, and running non-unified builds doesn't catch them.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ted Mielczarek]

On 12/2/2013 11:39 PM, Mike Hommey wrote:
> Current setup (16):
>   real11m7.986s
>   user63m48.075s
>   sys 3m24.677s
>   Size of the objdir: 3.4GiB
>   Size of libxul.so: 455MB
>
Just out of curiosity, did you try with greater than 16?

-Ted

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ehsan Akhgari]

I think that in order to fix the memory usage issues, we may need to 
adjust the number of unified sources at a per-directory level.  For 
example, I would expect the compiler to consume more memory compiling 
more C++ feature heavy code such as the typical JS engine source code 
than the average Gecko code.  Therefore I'm more interested to see 
people file bugs about specific memory usage problems that we can 
address on a more granular level.  I don't think that decreasing this 
number across the tree will buy us anything significant.


Cheers,
Ehsan

On 12/2/2013, 11:39 PM, Mike Hommey wrote:

Hi,

It was already mentioned that unified builds might be causing memory
issues. Since the number of unified sources (16) was decided more or
less arbitrarily (in fact, it's just using whatever was used for
ipdl/webidl builds, which, in turn just used whatever seemed a good
tradeoff between clobber build and incremental build with a single .cpp
changing), it would be good to make an informed decision about the
number of unified sources.

So, now that mozilla-inbound (finally) builds with different numbers of
unified sources (after fixing bugs 944844 and 945563, but how long
before another problem slips in?[1]), I got some build time numbers on my
machine (linux, old i7, 16GB RAM) to give some perspective:

Current setup (16):
   real11m7.986s
   user63m48.075s
   sys 3m24.677s
   Size of the objdir: 3.4GiB
   Size of libxul.so: 455MB

12 unified sources (requires additional patches for yet-to-be-filed bugs
(yes, plural)):
   real  11m18.572s
   user  65m24.145s
   sys   3m28.113s
   Size of the objdir: 3.5GiB
   Size of libxul.so: 464MB

8 unified sources:
   real11m47.825s
   user68m21.888s
   sys 3m39.406s
   Size of the objdir: 3.6GiB
   Size of libxul.so: 476MB

4 unified sources:
   real  12m52.630s
   user  76m41.208s
   sys   4m2.783s
   Size of the objdir: 3.9GiB
   Size of libxul.so: 509MB

2 unified sources:
   real  14m59.050s
   user  90m44.928s
   sys   4m45.418s
   Size of the objdir: 4.3GiB
   Size of libxul.so: 561MB

disabled unified sources:
   real  18m1.001s
   user  113m0.524s
   sys   5m57.970s
   Size of the objdir: 4.9GiB
   Size of libxul.so: 628MB

Mike

1. By the way, those type of bugs that show up at different number of
unified sources are existing type of problems waiting to arise when we
add source files, and running non-unified builds doesn't catch them.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Ehsan Akhgari]

On 12/3/2013, 12:31 AM, Mike Hommey wrote:

On Tue, Dec 03, 2013 at 12:18:46AM -0500, Boris Zbarsky wrote:

On 12/2/13 11:39 PM, Mike Hommey wrote:

1. By the way, those type of bugs that show up at different number of
unified sources are existing type of problems waiting to arise when we
add source files, and running non-unified builds doesn't catch them.


A number of the ones I saw you file seemed to do with #defines in
.cpp files that then affect other .cpp files.

I would argue that any .cpp file that #defines something and doesn't
#undef it shouldn't be unified...  Is there any way we can enforce
that at compile-time?


Those bugs you're talking about are really about a macro having the
same name as something else in the tree. We just happen to be lucky that
those instances of macros are in .cpp files, but they could very well
have been in headers, and we might have such problems in hiding already.

So if we go after something at the static analysis level, that should be
that as well, not only that #defines are #undefed.


Also note that any .cpp file which includes any headers has at east one 
macro that it won't #undef (for the include guard.)  I don't think that 
restriction is practical to enforce.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Mike Hommey]

On Tue, Dec 03, 2013 at 12:18:46AM -0500, Boris Zbarsky wrote:
> On 12/2/13 11:39 PM, Mike Hommey wrote:
> >1. By the way, those type of bugs that show up at different number of
> >unified sources are existing type of problems waiting to arise when we
> >add source files, and running non-unified builds doesn't catch them.
> 
> A number of the ones I saw you file seemed to do with #defines in
> .cpp files that then affect other .cpp files.
> 
> I would argue that any .cpp file that #defines something and doesn't
> #undef it shouldn't be unified...  Is there any way we can enforce
> that at compile-time?

Those bugs you're talking about are really about a macro having the
same name as something else in the tree. We just happen to be lucky that
those instances of macros are in .cpp files, but they could very well
have been in headers, and we might have such problems in hiding already.

So if we go after something at the static analysis level, that should be
that as well, not only that #defines are #undefed.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deciding whether to change the number of unified sources

[Boris Zbarsky]

On 12/2/13 11:39 PM, Mike Hommey wrote:

1. By the way, those type of bugs that show up at different number of
unified sources are existing type of problems waiting to arise when we
add source files, and running non-unified builds doesn't catch them.


A number of the ones I saw you file seemed to do with #defines in .cpp 
files that then affect other .cpp files.


I would argue that any .cpp file that #defines something and doesn't 
#undef it shouldn't be unified...  Is there any way we can enforce that 
at compile-time?


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Deciding whether to change the number of unified sources

[Mike Hommey]

Hi,

It was already mentioned that unified builds might be causing memory
issues. Since the number of unified sources (16) was decided more or
less arbitrarily (in fact, it's just using whatever was used for
ipdl/webidl builds, which, in turn just used whatever seemed a good
tradeoff between clobber build and incremental build with a single .cpp
changing), it would be good to make an informed decision about the
number of unified sources.

So, now that mozilla-inbound (finally) builds with different numbers of
unified sources (after fixing bugs 944844 and 945563, but how long
before another problem slips in?[1]), I got some build time numbers on my
machine (linux, old i7, 16GB RAM) to give some perspective:

Current setup (16):
  real11m7.986s
  user63m48.075s
  sys 3m24.677s
  Size of the objdir: 3.4GiB
  Size of libxul.so: 455MB

12 unified sources (requires additional patches for yet-to-be-filed bugs
(yes, plural)):
  real  11m18.572s
  user  65m24.145s
  sys   3m28.113s
  Size of the objdir: 3.5GiB
  Size of libxul.so: 464MB

8 unified sources:
  real11m47.825s
  user68m21.888s
  sys 3m39.406s
  Size of the objdir: 3.6GiB
  Size of libxul.so: 476MB

4 unified sources:
  real  12m52.630s
  user  76m41.208s
  sys   4m2.783s
  Size of the objdir: 3.9GiB
  Size of libxul.so: 509MB

2 unified sources:
  real  14m59.050s
  user  90m44.928s
  sys   4m45.418s
  Size of the objdir: 4.3GiB
  Size of libxul.so: 561MB

disabled unified sources:
  real  18m1.001s
  user  113m0.524s
  sys   5m57.970s
  Size of the objdir: 4.9GiB
  Size of libxul.so: 628MB

Mike

1. By the way, those type of bugs that show up at different number of
unified sources are existing type of problems waiting to arise when we
add source files, and running non-unified builds doesn't catch them.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform