In a message dated 3/31/05 9:12:15 PM, [EMAIL PROTECTED] writes:


But, (there's always a "but",) it appears that TCMalloc is a
wholesale-retail allocator just like our Zippy (aka Tcl's threaded
memory allocator).� In other words, it would seem that using TCMalloc
won't offer us any performance increase over the current Tcl threaded
memory allocator -- I'll have to experiment to see if this is true or
not.� There's a good chance that the Google guys implemented their
allocator in a more clever fashion than the Tcl threaded memory
allocator.




Hi,

I quickly read through the info.  The design for small-allocations is similar to zippy so I agree, likely limited performance improvement in the key area of lock contention avoidance.  However, for larger allocations TCMalloc looks much more sophisticated and the profiling features look good.  And, as it's a direct malloc replacement we can avoid crashes with zippy when folks ns_malloc and then free.

So, seems like the thing to try is build Tcl without zippy (--disable-thread-alloc I think) then preload tcmalloc and see how it works out.

-Jim
2">

Reply via email to