I need to shave off as much memory as possible. I am using standard C++ with STL. The program does not do much (yet) and it still takes 960Kb [according to top]! The executabe size is only 64KB.
The code is 3000 lines long, I am not going to post obviously. I believe the problem is not with my code, but with the system libraries.
A single main() function (includes all my code but doesn't use it) uses 732Kb of RAM!
Simple Code:
int main() {
sleep(1000); //do nothing
return 0;
}
//Uses 732kb of RAM
My code has no global variables (apart from ones in libraries that are hidden from me).
I am using standard libraries: libstdc++ (STL), GNU libc. Also a single BSD socket and libev and the non-standard STL rope class.
Is there some memory-profiler I can run?
Platform: Linux 2.6.18-32, 32-bit processor, 16MB total system RAM, no swap available
Compiler: GCC 4
Standard Library: GCC's libstdc++
Compiler Options: -Os (no debugging symbols)
I am not making heavy use of templates: containers and iterators that's all. However I am making heavy use of the SGI STL rope class.
The test environment is a basic server running Linux with 128MB RAM, Pentium III 667 Mhz, CentOS 5.5, no emulation.
UPDATE: I am wondering if the libraries themselves (code size) are causing the problem. Doesn't shared libraries require to be loaded into RAM?
Start stripping out functionality until the memory usage goes down. Go extreme first -- if you can replace main with sleep(1000); and your memory use is still high, look to code and static data -- anything initialized at global scope or static inside a class or function, along with template instantiations of different types and debug symbols.
UPDATE: Removed incorrect commentary about STL allocators. It may apply to other compiler/STL versions (check the history if you want to see it) but it's not applicable to this question.
Be aware that malloc/operator new will often be stingy about giving free memory back to the OS, which will cause your program as a whole not to shrink its apparent usage over time; that memory will get reused throughout your program by future allocations, so it's usually not a huge issue aside from keeping your "memory use" numbers at or near their high-water mark indefinitely.