From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2369 invoked by alias); 28 Feb 2004 00:21:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2354 invoked from network); 28 Feb 2004 00:21:05 -0000 Received: from unknown (HELO scanner2.ics.uci.edu) (128.195.1.36) by sources.redhat.com with SMTP; 28 Feb 2004 00:21:05 -0000 Received: from vino.ics.uci.edu (vino.ics.uci.edu [128.195.11.198]) by scanner2.ics.uci.edu (8.12.10/8.12.10) with ESMTP id i1S0KZ4J006446; Fri, 27 Feb 2004 16:20:35 -0800 (PST) Message-Id: <200402280020.i1S0KZ4J006446@scanner2.ics.uci.edu> To: Robert Bowdidge Cc: gcc@gcc.gnu.org Subject: Re: cutting the size of CONST_DECLs References: <2B448A8E-6977-11D8-B63F-000A957D89DA@apple.com> From: Dan Nicolaescu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Feb 2004 01:09:00 -0000 X-ICS-MailScanner-smtp3: Found to be clean X-ICS-MailScanner-SpamCheck-smtp3: not spam (whitelisted), SpamAssassin (score=-113.1, required 5, EMAIL_ATTRIBUTION, REFERENCES, USER_IN_WHITELIST) X-SW-Source: 2004-02/txt/msg01471.txt.bz2 Robert Bowdidge writes: > Hi, all, > > At Apple, the compiler's memory use (and its effect on compile speed) > is our biggest concern. One specific worry is declarations. On > common Mac programs which include headers for our GUI libraries, > declarations fill a significant amount of garbage-collected memory. > With -fmem-report, we usually see about 35% of memory filled with > declarations. > CONST_DECLs are an obvious offender in our programs; many of the Mac > headers make heavy use of enums to define symbolic constants. In > some programs, CONST_DECLS are the third most common kind of > declaration after FUNCTION_DECL and PARM_DECL, and can be responsible > for 30% of declarations and 10% of gc'd memory. > > I've tried one change to cut memory use: creating a new, smaller > structure for CONST_DECLs only, and having all other declarations > inherit this structure and extend it with the rest of the fields. On > a couple typical applications, this change cuts memory use by 4-6% and > compilation time by 0-3%. You might also want to look at doing something about FUNCTION_DECLs. There are a few fields in struct tree_decl that are only used for FUNCTION_DECLs: inlined_fns, saved_tree. If you somehow reorganize struct tree_decl and manage to leave these fields out for everything but FUNCTION_DECLs you will get some memory savings. Also "vindex" is only used for languages that use inheritance, so it is useless for C. Moving "vindex" to "lang_specific" might be interesting too.