[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Tons of reallocs in Lua - why?
- From: David Jones <drj@...>
- Date: Wed, 20 Dec 2006 10:52:53 +0000
On 10 Dec 2006, at 16:21, Ivan-Assen Ivanov wrote:
the recent thread about multithreaded allocation reminded me to
ask a question I'm wondering about for quite some time.
All of the Lua activity in our application happens in a single thread,
so I recently tried to supply to Lua a very fast, lightweight
allocator - the so-called TLSF. Imagine my surprise when everything
started running slower. The investigation showed that Lua performs an
insane (by the standards of the programming style I'm used to)
number of reallocs, and TLSF doesn't provide a reasonable
realloc at all, substituting it with a malloc+memcpy+free combination.
Just to clarify, the so-called TLSF is some memory manager that
you've custom written, right? It's not some standard or vendor
provided library that's been hammered on for years and has proven
reliability and performance (such as glibc or something like that).
Generally custom memory managers perform worse than commonly
available ones. Often even when written with particular domain
knowledge of the memory behavior of a certain program. If you have
measured a memory management performance problem, and you're using
malloc, the first thing to try should to use another well known
malloc. There are a few to choose from and a simple switch could
lead to 20% better performance. See Benjamin Zorn's paper: "The
Measured Cost of Conservative Garbage Collection", and in particular
section 5.2, "The effect of domain-specific allocator enhancements".
He concludes "that programmers, instead of spending time writing
domain-specific storage allocators, should consider using other
publicly available implementations of storage management algorithms
if the one they are using performs poorly." Get it at ftp://
Don't re-invent the wheel.