Free Software programmer
This blog existed before my current employment, and obviously reflects my own opinions and not theirs.
This work is licensed under a Creative Commons Attribution 2.1 Australia License.
Thu, 14 Dec 2006
But the "Caveats" caught my eye, particularly:
Why should it use that much memory? Since the arrays involved should be zero until used, surely it wouldn't take a 6MB hit until they were fully utilized?
So, I downloaded it and took a look. Erk. It's in C++! It astounds me that someone would write a low-level library like this in C++. Here's a simple "1-byte malloc then spin" program with glibc:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7078 rusty 21 0 1524 344 272 R 95.3 0.1 0:02.73 sleeptest
And linked against ctmalloc:
5946 rusty 24 0 4688 1456 908 R 80.2 0.3 0:02.77 sleeptest
Now 1.1MB isn't quite the 6MB quoted, but it's not good. Here's what size says:
$ size /usr/local/lib/libtcmalloc.so.0.0.0 text data bss dec hex filename 125231 1840 267624 394695 605c7 /usr/local/lib/libtcmalloc.so.0.0.0
125k of text seems excessive to me, but the 267k of BSS caught my eye. "static TCMalloc_Central_FreeListPadded central_cache[kNumClasses];" is 250k (kNumClasses is 170). In addition, initializing the library causes 4 128k allocs and a single 1Mb alloc. I'm guessing at least some of these are being helpfully initialized by C++ constructors, using up memory even if it's initialized to zero.
But because it was C++, my tolerance limit was reached and I stopped poking. My initial casual thought of integrating talloc has faded. But then, Andrew Tridgell once said "you never need a reason to rewrite something"!
[/tech] permanent link