From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32107 invoked by alias); 14 Feb 2004 14:27:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 32085 invoked by uid 48); 14 Feb 2004 14:27:26 -0000 Date: Sat, 14 Feb 2004 14:27:00 -0000 Message-ID: <20040214142726.32084.qmail@sources.redhat.com> From: "hubicka at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20031030234001.12850.jens.maurer@gmx.net> References: <20031030234001.12850.jens.maurer@gmx.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/12850] [3.4/3.5 Regression] memory consumption for heavy template instantiations tripled since 3.3 X-Bugzilla-Reason: CC X-SW-Source: 2004-02/txt/msg01467.txt.bz2 List-Id: ------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850