IMHO, it depends a lot on exactly what the app is doing.
I can think of a couple of possible reasons for the differences here:
- the time taken by the memory allocator itself (depends on how many, and what
sizes you're
asking for), and
- the exact placement of the memory can also (greatly) affect how long it takes
to
access that memory (due to cache effects, which depend on the pattern
of memory access in your app).
In the particular benchmark case I was looking at, I was seeing huge
differences
in performance,
just by changing either the sizes of the arrays the app was using, or the order
that the arrays
were placed in memory (e.g. A, B, C vs C, B, A). Since each malloc places
memory differently,
that could also explain some of the differences you're seeing with your app.
Mike
Matty wrote:
> On Wed, Apr 30, 2008 at 6:26 PM, David Lutz <[EMAIL PROTECTED]> wrote:
>> If your application is single threaded, you could try using the
>> bsdmalloc library. This is a fast malloc, but it is not multi-thread
>> safe and will also tend to use more memory than the default
>> malloc. For a comparison of different malloc libraries, look
>> at the NOTES section at the end of umem_alloc(3MALLOC).
>>
>> I got the following result with your example code:
>>
>>
>> $ gcc -O3 -o xml `/usr/bin/xml2-config --libs --cflags` xml.c
>> $ ./xml
>> 100000 iter in 21.445672 sec
>> $
>> $ gcc -O3 -o xml `/usr/bin/xml2-config --libs --cflags` xml.c -lbsdmalloc
>> $ ./xml
>> 100000 iter in 12.761969 sec
>> $
>>
>> I got similar results using Sun Studio 12.
>>
>> Again, bsdmalloc is not multi-thread safe, so use it with caution.
>
> Thanks David. Does anyone happen to know why the memory allocation
> libraries in Solaris are so much slower than their Linux counterparts? If
> the various malloc implementations were a second or two slower, I could
> understand. But they appear to be 10 - 12 seconds slower in our specific
> test case, which seems kinda odd.
>
> Thanks,
> - Ryan
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
