> Could you try an experiment and compile you sources with > /usr/lib/libast.so.1 (you need to compile the sources with > -I/usr/include/ast before /usr/include/ since libast uses a different > symbol namespace and cannot be used to "intercept" other > |malloc()|/|free()| calls like libbsdmalloc) ? AFAIK that should cure > the performance problem (assuming the library functions which heavily > use |malloc()|/|free()| are compiled against libast headers, too) ...
What would this experiment prove? The test program links to libxml2, libz, libm, and libc. It seems like it would be a lot of work to re-compile all of these libraries against libast headers just for amusement. In the case of libc, I'm not even sure it's possible. If libast has its own memory allocator, it would make a lot more sense to move that functionality into an interposition library like we already do for libumem, libmapmalloc, libwatchmalloc, libmtmalloc, and libbsdmalloc. -j
