This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/12850] [3.4/3.5 Regression] memory consumption for heavy template instantiations tripled since 3.3
- From: "hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Feb 2004 14:38:35 -0000
- Subject: [Bug c++/12850] [3.4/3.5 Regression] memory consumption for heavy template instantiations tripled since 3.3
- References: <20031030234001.12850.jens.maurer@gmx.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From hubicka at ucw dot cz 2004-02-14 14:38 -------
Subject: Re: [3.4/3.5 Regression] memory consumption for heavy template instantiations tripled since 3.3
>
> ------- Additional Comments From hubicka at gcc dot gnu dot org 2004-02-14 14:27 -------
> Memory usage is now at 104MB that is still more than 3.3 did, but give that this code is almost perfect testcase where unit-at-a-time shall lose, I think score is not bad.
> Mark's patches helped a lot to amount of garbage produced by C++ frontend on mainline now (reducing amount of garbage from 2GB to 700MB), but I think we can do significantly better still.
> One problem is large consumption of struct function (about 10% of memory surviving from frontend). Many of these struct functions are for functions that were never cgraph_finalize_function (either templates or unused functions). I think these should be freed but I don't know how.
> Also C++ frontend still produce a lot of gabrage(39MB of 700MB memory is needed) Major producers are:
> varray.c:161 (varray_grow) 20496 1473380 401588:1.600% 210256:0.532%
> cp/call.c:2181 (add_template_candidate_real) 96047 2339908 63560:2.051% 0:0.000%
> cp/name-lookup.c:1719 (set_identifier_type_value_with_scope) 151575 3031500 0:2.587% 0:0.000%
> tree.c:3962 (build_method_type_directly) 24117 2604636 482340:2.634% 1411456:3.574%
> cp/lex.c:773 (copy_decl) 31558 3408264 0:2.909% 2979720:7.545%
> cp/name-lookup.c:2800 (push_class_level_binding) 170972 3419440 0:2.918% 140:0.000%
> tree-inline.c:1970 (copy_tree_r) 176657 3606700 4084:3.081% 551820:1.397%
> cp/search.c:1200 (build_baselink) 168114 4034736 0:3.443% 552:0.001%
> cp/pt.c:6252 (tsubst_decl) 38668 4176144 0:3.564% 2390580:6.053%
> cp/name-lookup.c:4720 (store_bindings) 221688 4433760 0:3.784% 0:0.000%
> cp/pt.c:5738 (tsubst_template_args) 248319 5966576 74480:5.155% 570592:1.445%
> function.c:6397 (allocate_struct_function) 9158 4688896 1978128:5.689% 4087720:10.351%
> cp/pt.c:3814 (coerce_template_parms) 282818 6655016 65496:5.735% 46156:0.117%
> tree.c:3908 (build_function_type) 57993 6263244 1159860:6.335% 332672:0.842%
> (first percentage is garbage allocated, second percentage is amount of memory surviving to cgraph_optimize)
> Backend looks better now, produce about 300MB of additional garbage. About 10-20% can be saved by better aliasing and moving log links into separate structure. Overall we went from 4GB garbage to 900MB.
> I don't have enought knowledge of templates and name lookup to get things significantly better.
Actually I messed up the numbers. We produce 1.1GB of garbage in
frontend and 1.2GB in backend. I have about 30% rediction of backend
memory by mixture of retirincg line number notes, moving log links away
and fixing some of cselib datastructures.
One big problem is that inlined bodies remain reachable somehow. Partly
it is because of ABSTRACT_ORIGIN pointers after subsequent inlining but
I am not sure what is really causing the rest.
The amount of memory used by trees grows from 39MB to 100MB during
compilation stage.
Honza
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850