lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 2010-11-19 15:35, Mike Pall wrote:
This is often suggested, but rarely beneficial. All modern malloc
implementations already do exactly that: they keep lists of blocks
for common sizes and recycle them.
> Instead one should tune the malloc implementation to the usage
> patterns of the language. This is what I did with the built-in
> allocator in LuaJIT (a heavily modified dlmalloc descendant).

I'll second this: in an earlier life as an embedded systems engineer, when porting our product to a new platform the very first thing we would do would be to wrap the host malloc()/free() implementation with our own allocator, which grabbed big chunks from the host allocator and did our own allocation inside. The reason for this was that most embedded malloc implementations suck beyond my ability to describe in a family-friendly forum. We'd get substantial speed improvements *entirely* due to this optimisation.

So, while it's true that any decent malloc implementation should do this, there are an awful lot of malloc implementations that are not decent! (*cough*Windows*cough*) Anyone who cares about memory allocation speed should probably using their own memory allocator.

┌─── ───── ─────
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL