enormous executable

[Simon Marlow]

> "Julian Seward (Intl Vendor)" <v-julsew@microsoft.com> writes:
>=20
> > On Linux and probably most Unixes, the text and data segments
> > of the executable are loaded page-by-page into memory on
> > demand.  So having a lot of unused junk in the executable doesn't
> > necessarily increase the memory used, either real memory or
> > swap space. =20
>=20
> (Surely not swap, since code is just paged from the=20
> executable image :-)

Not if the executable comes from an NFS server - it might be quicker to
back it with swap space.  I believe this is what some OSs do (though not
Linux, I think).

> Surely the executable itself is only linked with the functions
> that are actually used by the program? =20

Sure, except that this is done at the level of granularity of a module,
which when we're talking about Haskell code tends to be quite large.
This is where GHC's -split-objs comes in: it splits modules into smaller
units, which reduces the chances that you end up linking with something
you don't need.

Actually static linking is better for locality in the binary, because
the memory paged into the running executable is more likely to be
densely packed with useful functions.  Shared libraries only really come
into their own when there are multiple running programs using the same
library - otherwise they are a loss for both performance and memory use.

> Or are you talking about working set? I'd expect a GUI library to
> have considerable initialization etc. code, which is used relatively
> rarely.  In that case, the waste is mostly disk space, which is
> abundant these days.=20
>=20
> My thought was, however, that the GUI toolkit is probably used by
> multiple other (non-haskell) programs, and could be usefully shared.=20

The C code in GTK lives in shared libraries, which are still dynamically
linked against the executable when you use GTK+HS.  It's just the
Haskell code which is statically linked.

Cheers,
	Simon