 |
lua-l archive |
|
|
||
|
On 10 Dec 2006, at 16:21, Ivan-Assen Ivanov wrote:
Hello, 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 single-threaded allocator - the so-called TLSF. Imagine my surprise when everything actuallystarted 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). Is it?
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:// ftp.cs.colorado.edu/pub/techreports/zorn/CU-CS-573-92.ps.Z
Don't re-invent the wheel. drj