Re: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: Loading credentials in verify callback just as needed ?

[B. Scott Michel]

On 8/31/2012 8:51 AM, B. Scott Michel wrote:

I'd hesitate before writing my own memory manager (essentially what
you're proposing with memory pools). There's a good chunk of literature
that demonstrates that customized memory management is inefficient. It's
also a good indication that there's a different problem that needs to be
addressed. If you're using Linux, malloc() is already managing pools of
memory, as is almost every other malloc() implementation since around 1990.

2 million malloc() calls probably needs to be fixed first. If that can't
be fixed, look at the algorithm and fix it. But think long and hard
before writing your own memory manager.


-scooter

For the academically inclined, Emery Berger's dissertation research is what you want to go look at:

OOPSLA 2002: Reconsidering Custom Memory Allocation
with Ben Zorn & Kathryn McKinley
We show that a good general-purpose allocator is better (faster and more space-efficient) than all styles of custom allocators except regions, but these have serious problems. We introduce reaps (regions + heaps), which combine the flexibility and space efficiency of heaps with the performance of regions.
Talk (PowerPoint).

OOPSLA 2005: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management
with Matthew Hertz.
This paper provides empirical answers to an age-old question: is garbage collection faster/slower/the same speed as malloc/free? We introduce oracular memory management, an approach that lets us measure unaltered Java programs as if they used malloc and free. The result: a good GC can match the performance of a good allocator, but it takes 5X more space. If physical memory is tight, however, conventional garbage collectors suffer an order-of-magnitude performance penalty.
Talk: PowerPoint, PDF.