"Hemmann, Volker Armin" <volker.armin.hemmann@...> posted
200703142003.11766.volker.armin.hemmann@..., excerpted below,
on  Wed, 14 Mar 2007 20:03:11 +0100:

> j2 for MAKEOPTS and +kdeenablefinal and after some time each one of the
> makejobs want 900mb ram. There are two libs where that happens, makes
> kdepim the slowest-to-compile packet for me. Wesnoth is also an
> offender. Some versions want 500mb+ at some point when compiling.

In general c++/g++ is FAR more memory and CPU intensive than gcc 
compiling C.  I look at it this way (non-technical explanation), the OOP 
functionality of C++ is a great productivity enhancement for programmers, 
making them more effective.  However, the tradeoff is that it makes the 
compiler work harder doing all the stuff automatically that the 
programmer didn't do manually.

For those of us using split KDE packages rather than the monolithic 
versions, kmail is the particular part of kdepim that requires the huge 
resources.  With USE=kdeenablefinal (which is designed for file 
distribution level compilation, and turns on a bunch of compile resource 
expensive optimizations to make run-time performance as good as 
possible), on AMD64 at least, one specific compile job in that package 
requires over a gig of memory at one particular point.  Anybody who has 
only a gig of memory WILL be in swap at that point, there's no way around 
it except to USE=-kdeenablefinal for that package, setting it in 
package.use or whatever.

It'd be interesting to be enough of a programmer to figure out exactly 
what's requiring all that memory, but it's beyond my rather limited 
capacities in that area, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list