Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

[Richard Guenther <rguenther at suse dot de>]

On Tue, 12 Dec 2006, Daniel Jacobowitz wrote:

> On Tue, Dec 12, 2006 at 03:36:32PM +0100, Michael Matz wrote:
> > Meanwhile it seems people downthread came to a preferred solution (listing 
> > template args explicitely).  I'm not sure how sensible that is given 
> > testcases like in PR29433 (the debug info will still be HUGE and basically 
> > useless) but we probably don't gain that capability immediately.  So, do 
> > people really think that until then we should continue to output multi-MB 
> > strings which no sane person is interested to look at in a debugger anyway 
> > just for sake of a weakly defined specification until we gain that 
> > possibility?
> 
> What else do you expect to happen?  You've created a type whose fully
> expanded name is 2MB, expect at least 2MB of debug info for it.  I
> can't readily see what the names look like from the test case, but
> the debug info might not be too large if there's substantial
> duplication in it - DIEs will be reused.
> 
> Sure, we could throttle the debug info and omit the name.  But that's
> much like reintroducing a 63 character (or however many) limit on
> unique identifiers; the debug info wouldn't unambiguously identify the
> source type.

I think we might get back some compile-time memory usage by constructing
the full names at debug output time.  If I remember correctly most of
the identifiers generated are for types that don't have their template
arguments fully substituted (so we won't see an instantiation of that
type or debug info).  But I might be wrong, as what happens there in
the C++ frontend is not entirely clear to me.

Now, we might be able to conditionalize the patch as is on not
generating debug info - this way memory usage for the -O0 case will
drop from ~2.5GB to 350MB.  With -O0 -g it will again be ~2.5GB.

Does that sound like a reasonable approach until we fix all the
debug info issues?

Thanks,
Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs