public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Lin George <george4academic@yahoo.com>
To: John Love-Jensen <eljay@adobe.com>, MSX to GCC <gcc-help@gcc.gnu.org>
Subject: Re: to reduce footprint
Date: Wed, 20 Dec 2006 16:46:00 -0000	[thread overview]
Message-ID: <20061220164547.28806.qmail@web32110.mail.mud.yahoo.com> (raw)

Thanks John! I want to reduce the file size of my shared library. I think you are an expert in this field. I have read through your comments below and I am especially interested in the following points,

1. Use footprint techniques (such as inheritance, specialization and partial
specialization) to reduce the amount of code generated by templates.

Could you provide some references to them?

2. Avoid the convenience of multiple copies of weak linkage for stronger,
explicit linkage.  [Depending on what kind of footprint you are trying to
reduce.]

Could you provide some reference about weak linker and a strong (explicit linker)?

3. Make sure all your header files do not emit any code (e.g., no static
variables in header files).  Compile your header files to confirm that all
your header files are non-code-generating.

I can understand what you mean, but I do not know why if header files emit code, the footprint will be larger?

4. --gc-sections -ffunction-sections -fdata-sections

gcc manual does not contain much information about these parameters. Could you briefly introduce the functions of them?


thanks in advance,
George


----- Original Message ----
From: John Love-Jensen <eljay@adobe.com>
To: Lin George <george4academic@yahoo.com>; MSX to GCC <gcc-help@gcc.gnu.org>
Sent: Tuesday, December 19, 2006 9:18:32 PM
Subject: Re: to reduce footprint


Hi George,

> I am wondering how to reduce the footprint of a binary build (C/C++) program
> generated by gcc.

Memory footprint, or file footprint?

> 1. Any ideas of reduce the footprint of a debug version build?
> 2. Any ideas of reduce the footprint of a release version build?

Just some suggestions, by no means a comprehensive list...

If you have an object file with 100 routines in it, but you only use 1
routine out of the hundred, isolate that one routine and link just it (.o
file).  Then you won't get the unnecessary 99 fallow routines.

Use footprint techniques (such as inheritance, specialization and partial
specialization) to reduce the amount of code generated by templates.

Avoid the convenience of multiple copies of weak linkage for stronger,
explicit linkage.  [Depending on what kind of footprint you are trying to
reduce.]

Make sure all your header files do not emit any code (e.g., no static
variables in header files).  Compile your header files to confirm that all
your header files are non-code-generating.

Use code coverage tools to identify code that is not used.  Figure out why
it isn't used, and consider if it can be disposed.

Use enums instead of strings for references to resources.

If you have a value range of, say, 0 to 100, and you have a large array of
them, consider using a typedef unsigned char uint8_t; instead of an array of
int to hold them.

> I think some linker or compiler options may help, what are they? Any other
> ideas to reduce footprint?

Depending on your platform, you may be able to use these switches:
--gc-sections -ffunction-sections -fdata-sections

hHTH,
--Eljay

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

             reply	other threads:[~2006-12-20 16:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-20 16:46 Lin George [this message]
2006-12-21 15:30 ` John Love-Jensen
  -- strict thread matches above, loose matches on Subject: below --
2006-12-21 17:50 Lin George
2006-12-21 19:13 ` John Love-Jensen
2006-12-19  2:41 Lin George
2006-12-19 13:18 ` John Love-Jensen

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=20061220164547.28806.qmail@web32110.mail.mud.yahoo.com \
    --to=george4academic@yahoo.com \
    --cc=eljay@adobe.com \
    --cc=gcc-help@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).