[opensource-dev] TCMalloc Memory Profiling?

Boroondas Gupte sllists at boroon.dasgupta.ch
Sat Oct 2 15:21:13 PDT 2010


 On 10/02/2010 09:57 PM, miss c wrote:
> I saw the memoryprofiling debug option to enable the TCMalloc's memory
> profiling.  Reading up on it here
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
I guess you're talking about the "MemProfiling" debug setting? (When
talking about less well known debug settings, please always mention
their exact name to avoid confusion. Sometimes there are several similar
ones.)

> Will this enhance the performance of my viewer or is this legacy?
While I don't know what that option does exactly, it sounds like it
doesn't choose which library to use for memory allocation, but rather
enables profiling *if* the used library is TCMalloc. I don't how
TCMalloc usage would be enabled, but I guess that'd be a compile time
option, not a run time one.

While the usage of TCMalloc might make things faster compared to other
malloc implementations, enabling /profiling/ (presumably: measuring how
many allocations happen where and when in the program) is more likely to
slows things down.

> If it will enhance it, why is this option not on by default?  Can
> someone enlighten me please?
According to
http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html ,
their heap profiling (which might well be what the debug option toggles)
"can be useful for

    * Figuring out what is in the program heap at any given time
    * Locating memory leaks
    * Finding places that do a lot of allocation"

This means it's mostly interesting for developers who are either
debugging something and thus want to see what happens in the memory
they've allocated or who are hunting memory leaks or other reasons of
extensive memory usage (or rapid allocation/deallocation cycles, etc.).
I don't think enabling it would directly benefit the typical end user in
any way.

Cheers,
Boroondas

PS: There's lots off guesswork involved in the above, so anyone who
knows more/better, please correct me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/6529d74b/attachment.htm 


More information about the opensource-dev mailing list