On Mon, May 11, 2009 at 08:35:40PM -0500, Bob Friesenhahn wrote: >>> Yes. I don't know what libjpeg itself does, but GraphicsMagick should >>> be performing a similar number of allocations (maybe 1000 small >>> allocations) regardless of the size of the JPEG file. >> >> There are some known issues with small allocations on Solaris. I think >> I included a bug-id in the e-mail pointer I sent you before. > > Right. I don't think that many small allocations is the issue at all. > To verify, I used a small JPEG file (producing a similar number of > allocations) and see that the time is 0m0.301s rather than 0m21.001s. > The SPOT profiler does not show that memory allocators or any other OS > related functionality is a factor. Instead it shows that memory access > is "slow" as if one allocator provides access to memory which is "faster" > (i.e. "hotter") than the other. This is certainly possible.
Ah, this is very interesting information. I believe that Mike or Bart looked at our memory allocation performance in the past and found that for certain workloads, (they were looking at performance in the context of SPECcpu) the allocator returned blocks that weren't optimally aligned. If you're seeing performance where the memory access is just slower, this is likely the case. One approach might be to dtrace the return values of the malloc calls to see what addresses the memory allocator is giving you. This would allow you to check whether the alignment is satisfactory or not. There are libc functions that allow the caller to specify a specific alignment, but that's probably not desireable for most applications. The guys who investigated the SPECcpu issues might have additional suggestions. They're lurking on the list here somewhere... -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
