Do you have a specific program in mind? If not, it's very difficult to give general advice. The only thing I can think of is to make sure you clear your containers after you're done with them (not normally relevant, but I'm working on a program centered around a recursive function right now so in my case it was a good idea to clear the containers that I was done with before making the recursive call), make sure you don't allocate more than you need unless you plan on needing more, etc.

In windows, a large section of the overhead comes from allocating system resources to open
up a window.
Console apps can avoid most of this overhead, but anything that needs a window to draw to takes 10+ megs of ram on average.

I've never had a problem with one of my programs taking up too much memory without some kind of memory leak, so I can't really offer any guidlines beyond obvious code-level stuff.

I think that a lot of IE's memory usage is image buffers so it doesn't constantly have to redraw the page you're looking at, but I'm not certain.

I really hate bloat, but it is important to understand what you are measuring. The Task Manager "mem size" ("working set" as defined by Win32 API) can be misleading both ways - it includes shared DLLs and doesn't count swapped pages. Use perfmon instead to determine "private bytes" (nonshareable committed mem) and "virtual bytes" (address space) usage.
The latter is not a problem; your app has several hundred MB to burn before you start impinging on preferred DLL load addresses. A handy trick for resizeable arrays that do not waste *physical* memory but also do not invalidate iterators is to preallocate virtual address range and only commit the pages you need.

Quote:In windows, a large section of the overhead comes from allocating system resources to open up a window.

hm, doubtful. Call the top 2 culprits managed environments like Java or .net (*) and libraries.
I have written code (in assembly) that creates a window, sets up OpenGL, renders a 3d chess environment and plays back a famous game - for a grand total of like 1400 bytes. (this kind of thing tends make people saying "compilers do a better job" hold their tongue :) )


* Funny quote from some Slashdot discussion:

Quote:
> "I sometimes find distributing an extra 30 MB [the .net run-time] a bit inconvenient."

Please download my new folding bicycle! Its lightweight aluminum frame means it's easily portable and rugged too! when not biking, fold it up and carry it under your arm like a briefcase! The perfect form of personal transportation!*

* Note: lightweight bicycle application is powered by a Soviet-era nuclear submarine, a separate download.

General tips?...

- use a custom memory manager that has decent tracking facilities, preferably attaching file and line information to each allocation in "profile" builds. Every once in a while during development, take a snapshot of the memory state and dump it as something like a CSV file (so you can load it into a spreadsheet and similar packages). Sort the spreadsheet by memory size then file/line location and go through every allocation made in your application and ask "is this allocation sane?". This is a common practice I've used at various companies during development of console games where memory is severely limited.


- be aware of alignment of data types within structures:

struct{ char x; long y; char z; long w;};

versus

struct{ long y; long w; char x; char z;};

with some machine architectures, the compiler will place padding after the "char" types in the first example so that each "long" is aligned at a nice address (cache line, SIMD requirement, "all longs at an even memory address" requirement with some non-x86 CPUs). General rule of thumb: order structures by largest type first.


- learn the overhead(s) of your memory allocator. A general allocator usually has to have some way of knowing what memory is allocated and how large each allocation is, this is usually at least 4 bytes, and can be as high as 64 bytes or more! Once you know the overhead of an allocation, take another look at the dump of your application's memory state (see first point) - lots of little 4 byte allocs at load/initialisation time that you thought made sense suddenly start to look a bit nasty...


- related to the above, for final/release builds - make the structure of a file on disk *exactly* the same as the structure that file will end up in once its in memory, then just "fix up" offsets into pointers at load time. You potentially save lots of allocator overhead compared to picking at little portions of the file, allocating memory then copying small parts into structures in memory. You get the added benefit of significantly improving loading times (if done right).


- to get a small executable size, there are file stripper programs available which will remove all not strictly necessary parts from PE EXEs, ELFs etc. To get an even smaller executable size, you can use an EXE packer such as UPX which will uncompress the executable into memory at load time.


- to get a really tiny executable size (<=64kb), you need to start using ASM in at least some parts of your code as well as thinking about code and data re-use as well as generation; it's not something I'd generally recommend these days, but it is fun to do at least once, it'll be how that C64 stuff was done (many moons ago I used to be a demo coder, writing some 1Kb Amiga demos for fun was very educational).


- there are compiler options that can help you. Some compilers can remove all duplicate literal strings automatically, some have whole program optimised linking (compilers usually spit out a bunch of *separate* object files, the linker then blindly links them together - even if there's code that could be shared between them).

Quote:Original post by Jan Wassenberg
[...]I have written code (in assembly) that creates a window, sets up OpenGL, renders a 3d chess environment and plays back a famous game - for a grand total of like 1400 bytes. (this kind of thing tends make people saying "compilers do a better job" hold their tongue :) )[...]

And I've written tic tac toe (with AI) in assembly using under 512 bytes, but that isn't the point.

The question is how much memory does your program use while running? Nobody cares about how much space the exe takes up - I've never seen one 'too big' unless you're moving stuff around on floppies still (in which case a compression tool will usually bring it down to size).