Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[=?iso-8859-1?Q?Jakob_=D8stergaard?=]

On Thu, Mar 22, 2001 at 12:23:15PM -0600, Kevin Buhr wrote:
> [e-mail] (Kevin Buhr) writes:
...
> I pulled the "gcc-3_0-branch" of GCC from CVS and compiled Mozilla
> under a 2.4.2 kernel.  The numbers I saw were:
> 
>     real    57m26.850s
>     user    96m57.490s
>     sys     3m16.780s
> 
> which are almost exactly the same as my GCC 2.95.2 numbers.  When I
> peeked at "/proc/<cc1plus>/maps" a few times, I counted ~150 lines,
> not ~2000.  On another, much smaller block of C++ code, I get similar
> results: no dramatic change in kernel time.
> 
> Either the Mozilla codebase and my other test case don't tickle the
> problem, or something has changed in 3.0's allocation scheme since
> RedHat 2.96 was built.

Mozilla uses C++ mainly as "extended C" - due to compatibility concerns.

Try compiling something like Qt/KDE/gtk-- which are really heavy on
templates (with all the benefits and drawbacks of that).

My code here is quite template heavy, and I suspect that's what's triggering
it.  In fact, I can't compile our development code with optimization, because
GCC runs out of memory (it only allocates some 300-500 MB, but each page has
it's own map in /proc/pid/maps, and a wc -l /proc/pid/maps doesn't finish for
minutes).  My typical GCC eats 100-200 MB and runs for several minutes.

You should benchmark this particular case with code that makes GCC eat
lots of memory, 100MB or more.  I've never seen Mozilla really make GCC
eat that much memory  -  other projects do.

-- 
................................................................
:   [e-mail]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: