From: Robert Bowdidge <bowdidge@apple.com>
To: Dan Nicolaescu <dann@godzilla.ics.uci.edu>
Cc: gcc@gcc.gnu.org, Robert Bowdidge <bowdidge@apple.com>
Subject: Re: cutting the size of CONST_DECLs
Date: Sat, 28 Feb 2004 02:38:00 -0000 [thread overview]
Message-ID: <A7318206-698A-11D8-B63F-000A957D89DA@apple.com> (raw)
In-Reply-To: <200402280020.i1S0KZ4J006446@scanner2.ics.uci.edu>
On Feb 27, 2004, at 4:20 PM, Dan Nicolaescu wrote:
> 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.
Yep, separating FUNCTION_DECLs from everything else would definitely
help. One problem is that function declarations aren't the most common
node we see when parsing our headers; in my examples, FUNCTION_DECLs
were only 14-20% of declarations. PARM_DECLs were usually 33-36% of
declarations, so separating them out makes twice the difference.
Here's the distributions of declaration kinds I saw on some example
compiles:
PARAM FN CONST TYPE FIELD VAR
FinderFE 30% 29% 24% 16% ? ?
gcc 30% 34% 10% 3% 21% 3%
rogue 27% 59% 0% 5% 9% 5%
AppearanceSample
36% 20% 18% 16% 7% 0%
SimpleText
33% 14% 28% 13% 11% 4%
Each represents declaration kinds found during compile of a
representative file. FinderFE is the C++ front end to the Mac OS
Finder. Appearance Sample and SimpleText are two GUI applications from
Apple's sample code; AppearanceSample is C++, and SimpleText C.
One possibility I've strongly considered is to have three levels of
declarations:
small: CONST_DECL
medium: PARM_DECL, TYPE_DECL,FIELD_DECL
large: FN_DECL, VAR_DECL
On 3.3, small declarations to 72 bytes, medium declarations 100 bytes,
and large declarations 116 bytes. I've done a few measurements with
this set of objects; memory use and compile times improve again from
the CONST_DECL/everything else scheme, though the memory improvements
are still in the <10% ballpark, and compile time improvements are much
smaller. I still need to do more measurements on non-Apple source
code, and double-check that the changes aren't slowing the compiler.
Adding different kinds of declarations adds a bit of overhead, so we
don't want to take this too far. At a minimum, the DECL_P() macro
needs to do more work to decide if a given node is a declaration. On a
stock system, this is a single comparison: is the tree code class 'd'?
With three kinds of declarations, I could make the tree code classes
'd', 'D', and '$'. With these characters, the test in DECL_P() can use
a bitmask to see if (tree_code & 0x1f) == 0x04 rather than doing three
comparisons.
Deciding which kinds of declarations behave similarly can be difficult
from just the table of access patterns. I ended up using concept
analysis to identify likely hierarchies. (Snelting and Tip,
"Understanding Class Hierarchies using Concept Analysis", ACM
Transactions on Programming Languages and Systems 22(3), May 2000).
There's a tool available on Sourceforge ("conexp") to draw an optimized
class hierarchy (well, a concept lattice) given a set of objects and
properties. The three-level scheme pretty much fell out once I looked
at the lattice.
Robert
prev parent reply other threads:[~2004-02-28 1:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-28 0:21 Robert Bowdidge
2004-02-28 1:09 ` Dan Nicolaescu
2004-02-28 2:38 ` Robert Bowdidge [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A7318206-698A-11D8-B63F-000A957D89DA@apple.com \
--to=bowdidge@apple.com \
--cc=dann@godzilla.ics.uci.edu \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).