On Mon, 11 May 2009, johan...@sun.com wrote:
I'm not entirely convinced that this is simply the difference between memory mapped allocations versus sbrk allocations. If you compare the numbers between malloc and umem, notice that the overall increase in real time is due to the extra 5 seconds spent in user time in umem.
Yes, but the user time is virtually the same between -lumem and -lmapmalloc. It seems to me that if the application incurs a page fault that part of that page fault may be attributed to user time and the rest is not attributed to the process at all.
However, mapmalloc increases both the system and user time when compared to malloc.
Yes. User time with mapmalloc is the same as umem, but system time is somewhat increased.
There have been some past discussions on this list about identifying problems with memory allocations, and applications that allocate memory inefficiently. If your application is performing a lot of small memory allocations, it's possible that you're seeing poor performance for that reason.
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.
I would take a look at how your application is allocating memory, and where it's spending its time in these two different libraries. That might shed some light on what the problem is.
SPOT says that most time is spent executing libjpeg code (primarily ycc_rgb_convert) and that there is quite a lot of application stall with "LD/ST Unit Full" at a wopping 49.7%. When using -lumem, the program seems to spend 45% of the time waiting. This is definitely not the case for the rest of GraphicsMagick.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
