Created attachment 64191 [details]
Precompiler output

Command line used for compiling:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wformat -MT LanguageCode.lo -MD -MP -MF .deps/LanguageCode.Tpo -c LanguageCode.cc  -fPIC -DPIC -o LanguageCode.o

I don't think we can do anything about this.  Also I don't consider this memory usage excessive.  Until I have a machine that plays well with oprofile again I'm not looking into this further.

Well, having g++ crunching along for almost 10 minutes on an AMD64 3400+ system does make me nervous ...

I cannot reproduce this long CPU time (you don't go into swap, aren't you?).  On
Intel EMT64 3GHz compilation (of the .i file) takes 1m12s and uses max. 423MB of
virtual memory.  Maybe dependency generation and disk I/O is dominating for you?

If you think you can reproduce it, can you post the output of -ftime-report here?

Btw. the source of the problem is excessive inlining and exception handling making the CFG of CodeMaps::CodeMaps() explode.

I'm trying if removal of some of the 50k SSA temps helps (backporting a patch from 4.2 for this).

Sure, my machine is swapping with g++ using up to 650MB (with 512MB main memory).
But since all other files of this lib are compiling quite fast, I had the suspicion that there is some C++ construct causing this.

Comment #6 is exactly what I wanted to know, many thanks for this information.

I'll try -ftime-report now.

Backporting the patch from 4.2 doesn't really help.  Memory usage goes down 3MB, compile time about 1s.  Not worth a backport.

One way to cut down compile-time and memory usage would be to use a loop like

  for (i=0; i<size; ++i)
    iso639_2[static_data[i].short] = static_data[i].long;

and having a static array of structures containing the "xxx" -> long name
mappings.

Thanks Richard !

Down to enhancement. Assigning to ma@suse.de

I dont't think it's worth keeping it as a bug.

We just removed the static maps because statics in other translation units 
show up and refer to these values. Sometimes before they are actually 
initialized. 

Once coding has settled down, we'll take care of this, and properly adjust the initialization of the static vars. But currently it's a minor problem.

(In fact I wonder that your machine choked up on LanguageCode. Didn't it reach the Spirit parser ;)