Hi Bob,
The standard libc's malloc is thead-safe. If the applications doesn't
have the memory locks across different threads, I don't think libumem
may help its performance.
Regards,
Adam
Bob Friesenhahn 写道:
My multithread-enabled program is much slower at reading JPEG files
with the Solaris-provided libjpeg when it is linked against the umem
library than it is when it is linked against -lmalloc, -lmtmalloc, or
libc's malloc. Multiple threads are not used in this case, but since
the program may use multiple threads, malloc needs to be thread safe.
Only traditional malloc(), realloc(), and free() are used. Testing is
done under Solaris 10U5 patched up to a recent kernel.
For the purposes of testing the program (GraphicsMagick 'convert') is
executed 20 times to read a JPEG file. These are the cumulative
timings with the various malloc libraries:
-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
Does anyone know why libjpeg's execution would be so much slower with
libumem than it is with the other Solaris mallocs? UMEM_DEBUG and
UMEM_LOGGING are not defined in the environment.
It seems that there is a clue since using -lmapmalloc provides timings
similar to -lumem:
real 0m21.023s
user 0m17.830s
sys 0m3.161s
Thanks,
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
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
