memory profiling

[Alexander Larsson]

On Tue, 2004-06-01 at 18:05, Havoc Pennington wrote:
> Hi,
> 
> How hard would it be to assign sub-application-granularity "blame" for
> all the memory used by a full desktop (GNOME+Evolution+Mozilla+OO.org)?
> 
> Something like:
> 
>    5M   sum of per-app icon theme caching
>    5M   sum of per-app base gtk_init() overhead
>    10M  sum of per-email data in Evolution 
>    7M   base evo overhead with no mail loaded
>    30M  sum of all executable pages (libraries and binaries)
>    ...
> 
> i.e. try to get an idea of where focused optimization could have the
> most impact on the desktop overall - what percentage of TOTAL memory
> usage for the whole desktop can be blamed on each optimizable item, with
> sufficient granularity to be useful.

I was once thinking about something like this. If you could get
allocations in each source file bundled in with the other allocations
from that file we'd get a pretty decent approximation of the memory use
for a certain class of objects (since each GObject is typically
implemented in one source file). If we also count the number of live
objects of each GType and match the GType to its implemented source file
we'd have pretty good data about things like average memory use for each
object type, total memory use for certain object types and number of
live objects of each type.

This should be implementable if you turn g_malloc into a macro that
expands to something with __FILE__ in it, altought it would require us
to rebuild the whole stack with this macro defined.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a globe-trotting guitar-strumming astronaut gone bad. She's a 
bloodthirsty paranoid pearl diver married to the Mob. They fight crime!