Hi ghostscripters, I'm benchmarking malloc(), and I'm asking you for help for benchmarking malloc() with ghostscript.
Historically, papers about new implementations of malloc have benchmarked ghostscript, along with many other experiments. They have had some trouble measuring performance, since ghostscript uses its own allocator. For example Evans06 says ( http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf) > gs overwhelmingly allocates either 240-byte objects or large objects, since it uses a custom allocator > internally. As a result, this benchmark stresses performance of large object allocation. I was wondering if there is any way to convince gs to simply call malloc() and free() for every object it wants, instead of using its internal allocator. I've looked (briefly) at the code in gsmalloc.c and gsmemory.c, and it's not clear whether this is reasonable idea. The comments talk about garbage collection and object relocation, so maybe it's just infeasible to think of calling malloc() and free() on every object. So here are my questions: 1) Is the internal allocator in ghostscript used primarily for performance, or for features such as garbage collection? 2) Would it be possible to use malloc/free more heavily so that I can find out how much of a performance difference there is? How would I do that? Any help would be appreciated. -Bradley
