> 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) ?
Yeah, I did some digging when I had a free moment. The following is
the most germane to your issue.
5070823 poor malloc() performance for small byte sizes
-j
On Thu, May 01, 2008 at 05:36:26PM -0400, Matty wrote:
> We are building our application as a 32-bit entity on both Linux and
> S
Part of the problem is that these allocations are very small:
# dtrace -n 'pid$target::malloc:entry { @a["allocsz"] = quantize(arg0); }' -c
/tmp/xml
allocsz
value - Distribution - count
1 |
Hey Dude,
I pulled down a copy of your test program and ran a few experiments.
$ time ./xml
10 iter in 22.715982 sec
real0m22.721s
user0m22.694s
sys 0m0.007s
This seems to indicate that all of our time is being spent in usermode, so
whatever it is in Solaris that is slower than L
