
"Julian Seward (Intl Vendor)"
writes: 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.
(Surely not swap, since code is just paged from the 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?
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.
My thought was, however, that the GUI toolkit is probably used by multiple other (non-haskell) programs, and could be usefully shared.
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
participants (1)
-
Simon Marlow