Creating really small binaries?

Creating really small binaries?

[Caffeine Junky]

I'm looking for tips on how to make my executables really tiny.

More specifically I'm interested in keeping the memory used by the
running executable really small.
I realize that much of it is determined by the compiler being used(GNAT,
Aonix, Green Hills, etc...) and the platform(using Linux 2.4 here). A
small executable on disk would be a nice bonus, but not particularly
important.
Since Ada has shown itself to be excellent for embedded systems, which
normally have much less RAM(if any at all) than the standard PC, I'm sure
that this is not much of a problem.

Now, I dont plan on linking to any shared C libs at first.(except of
course glibc which is usually used by default with GNAT on Linux
systems).

The only problem I forsee is when it comes time to do GUI work, which has
an unfortunate tendency to bloat things. I hope to overcome this by
creating a limited interface directly to XLib.

Of course there are all the standard tools such as -O2 and strip.

Any suggestions on where I should begin?

Re: Creating really small binaries?

[Stephen Leake]

Caffeine Junky <nospam@hotmail.com> writes:

> I'm looking for tips on how to make my executables really tiny.

Ok.

> More specifically I'm interested in keeping the memory used by the
> running executable really small. 

Ok; that's more specific.

> I realize that much of it is determined by the compiler being
> used(GNAT, Aonix, Green Hills, etc...) and the platform(using Linux
> 2.4 here). A small executable on disk would be a nice bonus, but not
> particularly important. Since Ada has shown itself to be excellent
> for embedded systems, which normally have much less RAM(if any at
> all) than the standard PC, I'm sure that this is not much of a
> problem.

Ok.

> Now, I dont plan on linking to any shared C libs at first.(except of
> course glibc which is usually used by default with GNAT on Linux
> systems).

You can avoid glibc as well, depending on your application.

> The only problem I forsee is when it comes time to do GUI work,
> which has an unfortunate tendency to bloat things. I hope to
> overcome this by creating a limited interface directly to XLib.

Hmm, XLib is presumably a huge C library, so you've changed your mind
on that?

Writing your own GUI on top of XLib may not be the best way to make
the in-memory image size smaller. You may not be as good a GUI
programmer as the people who wrote the existing layers :). I know I'm
not!

In addition, if the GUI layers are in shared libraries, are you
counting them as part of "your" executable image size? If not, then
use as many shared libraries as possible!

> Of course there are all the standard tools such as -O2 

Or -O3, inline options, suppress checks, eliminate unused subprograms, etc.

> and strip.

'strip' only changes the size of the executable on disk, not in ram.

> Any suggestions on where I should begin?

Define the requirements for your application. Define the features you
will need to meet those requirements. Design a system that is robust,
easy to test, and probably efficient in terms of in-memory image size.
while (not working) loop Compile it. Test it. end loop. See how big it
is. Look for places to make it smaller.

If you say more about your specific application, it might be possible
to give more precise help.

-- 
-- Stephe

Re: Creating really small binaries?

[Caffeine Junky]

On Tue, 18 Jun 2002 12:41:35 -0400, Stephen Leake wrote:


 Hmm, XLib is presumably a huge C library, so you've changed your mind on
> that?
> 
> Writing your own GUI on top of XLib may not be the best way to make the
> in-memory image size smaller. You may not be as good a GUI programmer as
> the people who wrote the existing layers :). I know I'm not!
> 
> In addition, if the GUI layers are in shared libraries, are you counting
> them as part of "your" executable image size? If not, then use as many
> shared libraries as possible!
> 

Good point. I must admit to being influenced by the guys over at
radsoft.net(They wrote a windows explorer replacement in about 14kb). My
basic assumption(although I could be mistaken) is that by avoiding
additional layers(such as Gnome and KDE) it'll be easier to keep the size
down and the speed up.

> Define the requirements for your application. Define the features you
> will need to meet those requirements. Design a system that is robust,
> easy to test, and probably efficient in terms of in-memory image size.
> while (not working) loop Compile it. Test it. end loop. See how big it
> is. Look for places to make it smaller.
> 
> If you say more about your specific application, it might be possible to
> give more precise help.
 
Generally I'm looking for some rules of thumb that I can apply to small
projects. Such as a Database UI, or a Text Editor, etc... 
Right now I'm working on what will hopefully be a decent "E-Book" reader
that I could patch into a back-end database for storing notes,
annotations, bibliographies, etc... Something that can be used for very
large texts.(An Encyclopedia, The Bible, Collected Works of Shakespear,
The Common Lisp Standard, etc...).

As you can imagine, the GUI work on this one would be rather extensive. I
plan on Open Sourcing it, so people will be free to critique it. 

Anyways, I hate having applications/libraries that just suck up oodles of
system resources all on thier own. I want to prevent that, and keep the
application running smooth as a babies butt. GC is one way to go about
it, and that's not out of the question. But before going into
implementing GC, I try to make sure the rest of the app is as efficient
as I can possibly make it.

I hope that helps a little.


Caffinator

Re: Creating really small binaries?

[Stephen Leake]

Caffeine Junky <nospam@hotmail.com> writes:

> On Tue, 18 Jun 2002 12:41:35 -0400, Stephen Leake wrote:
> > Define the requirements for your application. Define the features you
> > will need to meet those requirements. Design a system that is robust,
> > easy to test, and probably efficient in terms of in-memory image size.
> > while (not working) loop Compile it. Test it. end loop. See how big it
> > is. Look for places to make it smaller.
> > 
> > If you say more about your specific application, it might be possible to
> > give more precise help.
>  
> Generally I'm looking for some rules of thumb that I can apply to small
> projects. Such as a Database UI, or a Text Editor, etc... 

Why is code size a criterium for either of these? They should not be
"huge", but they don't have to be "small". Or at least, that's way
less important than "does what I need, doesn't crash".

> Right now I'm working on what will hopefully be a decent "E-Book"
> reader that I could patch into a back-end database for storing
> notes, annotations, bibliographies, etc... Something that can be
> used for very large texts.(An Encyclopedia, The Bible, Collected
> Works of Shakespear, The Common Lisp Standard, etc...).
> 
> As you can imagine, the GUI work on this one would be rather extensive. I
> plan on Open Sourcing it, so people will be free to critique it. 
> 
> Anyways, I hate having applications/libraries that just suck up oodles of
> system resources all on thier own. 

Well, until you quantify "oodles", I'm not sure whether I agree or
not. 

Applications should not use resources they don't really need, and they
should attempt to reuse resources rather than simply requesting more.
But if the "typical" machine has enough resources to run the app, I
would not spend any time on making it more efficient.

> I want to prevent that, and keep the application running smooth as a
> babies butt. 

"Running smooth" and "using few resources" are not equivalent. Running
out of resources was a typical problem in Windows 3.1, and may be a
typical problem in embedded systems. But it should not be a typical
problem for a database GUI. If it is, then I agree you need to pay
attention to it.

> GC is one way to go about it, and that's not out of the question.
> But before going into implementing GC, I try to make sure the rest
> of the app is as efficient as I can possibly make it.

If by "GC" you mean "automatic recycling of resources", then put that
in _first_! That _is_ they way to make the app "as efficient as you
can possibly make it". Use Controlled types for any resources
requested from the OS/GUI, so you can be sure they are released
properly. 

-- 
-- Stephe

RE: Creating really small binaries?

[Robert C. Leif]

From: Bob Leif
To: Stephen Leake et al.
An Ada J code compiler may produce smaller executables.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Stephen Leake
Sent: Tuesday, June 18, 2002 9:42 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Creating really small binaries?

Caffeine Junky <nospam@hotmail.com> writes:

> I'm looking for tips on how to make my executables really tiny.

Ok.

> More specifically I'm interested in keeping the memory used by the
> running executable really small. 

Ok; that's more specific.

> I realize that much of it is determined by the compiler being
> used(GNAT, Aonix, Green Hills, etc...) and the platform(using Linux
> 2.4 here). A small executable on disk would be a nice bonus, but not
> particularly important. Since Ada has shown itself to be excellent
> for embedded systems, which normally have much less RAM(if any at
> all) than the standard PC, I'm sure that this is not much of a
> problem.

Ok.

> Now, I dont plan on linking to any shared C libs at first.(except of
> course glibc which is usually used by default with GNAT on Linux
> systems).

You can avoid glibc as well, depending on your application.

> The only problem I forsee is when it comes time to do GUI work,
> which has an unfortunate tendency to bloat things. I hope to
> overcome this by creating a limited interface directly to XLib.

Hmm, XLib is presumably a huge C library, so you've changed your mind
on that?

Writing your own GUI on top of XLib may not be the best way to make
the in-memory image size smaller. You may not be as good a GUI
programmer as the people who wrote the existing layers :). I know I'm
not!

In addition, if the GUI layers are in shared libraries, are you
counting them as part of "your" executable image size? If not, then
use as many shared libraries as possible!

> Of course there are all the standard tools such as -O2 

Or -O3, inline options, suppress checks, eliminate unused subprograms,
etc.

> and strip.

'strip' only changes the size of the executable on disk, not in ram.

> Any suggestions on where I should begin?

Define the requirements for your application. Define the features you
will need to meet those requirements. Design a system that is robust,
easy to test, and probably efficient in terms of in-memory image size.
while (not working) loop Compile it. Test it. end loop. See how big it
is. Look for places to make it smaller.

If you say more about your specific application, it might be possible
to give more precise help.

-- 
-- Stephe

Re: Creating really small binaries?

[Robert Dewar]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<u1yb4zghs.fsf@gsfc.nasa.gov>...

> Or -O3, inline options, suppress checks, eliminate unused subprograms, etc.

-O3 can only make executables larger, same with inlining, so this is
not a good idea!

Re: Creating really small binaries?

[Stephen Leake]

dewar@gnat.com (Robert Dewar) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:<u1yb4zghs.fsf@gsfc.nasa.gov>... 
> 
> > Or -O3, inline options, suppress checks, eliminate unused subprograms, etc.
> 
> -O3 can only make executables larger, same with inlining, so this is
> not a good idea!

I believe I have seen programs where the combination of -O3 with
inlining made things smaller. The inlined program could be better
optimized than the non-inlined program, and the inlined subprogram was
only used in one place. Whole branches of if statements could be
eliminated, because the condition was known to be static in the
inlined case. Well, maybe it was -O2; I'm not sure.

I don't have an example handy.

The point was to try all the options, and measure the result.
Sometimes the results are surprising, so it's worth trying.

-- 
-- Stephe

Re: Creating really small binaries?

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

>> -O3 can only make executables larger, same with inlining, so this is
>> not a good idea!
>
> I believe I have seen programs where the combination of -O3 with
> inlining made things smaller.

If there's a platform on which GNAT supports subprogram-level linking
(I don't know if such a platform does exist), this could indeed
happen.  Without it, it's hardly believable, because the non-inlined
copy will be pulled in in almost all cases.

IIRC, C++ code which uses templates heavily benefits from inlining
also in terms of code size, but the GNAT implementation of generics is
so different that this effect cannot show up.