Bug 144306

Summary:	Excessive memory usage of G++ on x86_64
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Klaus Kämpf <kkaempf>
Component:	Development	Assignee:	Michael Andres <ma>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	rguenther
Version:	Beta 1
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:	164055
Bug Blocks:
Attachments:	Precompiler output

Description Klaus Kämpf 2006-01-20 10:37:20 UTC

Attached (precompiled) file leads to excessive memory/cpu usage (440M Virt, 280M Res, ~90% CPU)

Comment 1 Klaus Kämpf 2006-01-20 10:38:46 UTC

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

Comment 2 Richard Biener 2006-01-20 11:02:09 UTC

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.

Comment 3 Klaus Kämpf 2006-01-20 11:11:38 UTC

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

Comment 4 Richard Biener 2006-01-20 11:23:15 UTC

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?

Comment 5 Richard Biener 2006-01-20 11:25:29 UTC

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

Comment 6 Richard Biener 2006-01-20 11:38:13 UTC

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

Comment 7 Richard Biener 2006-01-20 11:44:07 UTC

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

Comment 8 Klaus Kämpf 2006-01-20 12:03:12 UTC

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.

Comment 9 Richard Biener 2006-01-20 12:06:42 UTC

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

Comment 10 Richard Biener 2006-01-20 12:15:29 UTC

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.

Comment 11 Klaus Kämpf 2006-01-20 13:00:51 UTC

Thanks Richard !

Down to enhancement. Assigning to ma@suse.de

Comment 12 Michael Andres 2006-01-20 17:39:38 UTC

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 ;)