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
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
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 yo
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
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
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 th
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 lib
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
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 performanc
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.
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
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
>>>
>>> Ju
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
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
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 sourc
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
__
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 G
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 sour
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 bu
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
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 clobbe
21 matches
Mail list logo
