"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
email@example.com mailing list