On 22.12.2006, at 15:59, Vlad Seryakov wrote:
Try malloctest, tclalloctest is not real test, it just calls
TclThreadAllocObj to see how fast is local linked list, really does
not test
On Solaris:
-bash-3.00$ ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 86483 usec
-bash-3.00$ ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 86929 usec
-bash-3.00$ ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 81667 usec
On Mac:
iMac1:~/vmalloc zoran$ ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 519085 usec
iMac1:~/vmalloc zoran$ ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 369680 usec
iMac1:~/vmalloc zoran$ ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 377635 usec
A SuSE 9.2 Linux on a AMD Athlon XP 2200+
[EMAIL PROTECTED]:~/vmalloc> ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 61715 usec
[EMAIL PROTECTED]:~/vmalloc> ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 77526 usec
[EMAIL PROTECTED]:~/vmalloc> ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 68874 usec
This proves what I've found already: Mac OSX malloc is slow.
Solaris and Linux standard malloc are fast enough.
Generally, on modern Solaris or Linux, you need not fiddle with any
external malloc routine. The built-in malloc is optimal in terms of
speed and memory usage.
The other extreme is Mac OSX. There you need some kind of external
malloc handling.
I guess, after all this endeavours, that it is really not that important
to cook up your own malloc routine nowdays. Standard OS tools are fully
acceptable (with a Mac OSX being a notable exception).
