johan...@sun.com wrote: > On Mon, May 11, 2009 at 11:10:37AM -0500, Bob Friesenhahn wrote: > > It seems that the performance issue stems from libumem using memory > > mapped allocations rather than sbrk allocations. I have not seen a > > performance impact from using libumem in any other part of the software. > > The performance hit in libjpeg is pretty severe. > >> > >> -lmalloc: > >> real 0m16.134s > >> user 0m12.905s > >> sys 0m2.253s > >> > >> -lmtmalloc: > >> real 0m16.275s > >> user 0m12.969s > >> sys 0m2.267s > >> > >> -lumem: > >> real 0m21.003s > >> user 0m17.744s > >> sys 0m2.251s > >> > >> -lmapmalloc: > >> real 0m21.023s > >> user 0m17.830s > >> sys 0m3.161s > > 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. > > However, mapmalloc increases both the system and user time when compared > to malloc. > > 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. > > > http://mail.opensolaris.org/pipermail/perf-discuss/2008-May/003393.html
Can you check whether the memory allocator in libast performs better in this case (e.g. compile with $ cc -I/usr/include/ast/ -last ... # (note: libast uses a |_ast_|-prefix for all symbols and does (currently) not act as |malloc()| interposer)). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
