1 Apr 2005 freetype   » (Master)

Shared Libraries and Memory Usage on Linux

I've written a small program to measure the 'memory payload' of using shared libraries on Linux. What it shows is the amount of private process memory that is taken by the simple fact of _linking_ a program to a shared object. This corresponds roughly to the following data:

  • the specific position-independent-code tables, like the GOT, PLT and DLT. These are automatically generated by the dynamic loader. The more functions the library imports/exports, the bigger these tables are. They also explain why _any_ shared library uses at least 4 KB/process.

  • any writable static data used by the library itself.

  • finally, any absolute pointer constant found in the library, since these cannot be placed within PIC code. Any C++ shared library is going to have all of its vtables in the .data section for this reason.

Note that this does not include the memory used by the libraries when they're used (e.g. when allocating from the heap with 'malloc').

The code is available here. Python 2.1 or above required.

Results are interesting. On my work system (RedHat 7.3), the biggest "eaters" are the following:

 process     KB    KB per    library
   count  total   process
       8   1312       164    /usr/lib/qt-2.3.1/lib/libqt.so.2.3.1
      59   1180        20    /lib/i686/libc-2.2.4.so
       8    768        96    /usr/lib/libkdeui.so.3.0.0
      18    576        32    /lib/i686/libpthread-0.9.so
       5    440        88    /local/dturner/opt/lib/libstdc++.so.5.0.5
      19    304        16    /usr/X11R6/lib/libX11.so.6.2
       8    256        32    /usr/lib/libkdecore.so.3.0.0
      59    236         4    /lib/ld-2.2.4.so
       8    224        28    /usr/lib/libstdc++-3-libc6-2-2-2.10.0.so
       4    192        48    /lib/libcrypto.so.0.9.6b
total payload = 10044 KB

This seems pretty reasonnable, though there are some surprises here (it's an XFCE desktop with only two KDE apps opened, no KDM !). I'd better run the script on more recent distributions to see how they compare however.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!