[WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: Loading credentials in verify callback just as needed ?
B. Scott Michel
scottm at aero.org
Fri Aug 31 17:55:02 CEST 2012
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.
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 <http://research.microsoft.com/%7Ezorn> & Kathryn
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) <http://www.cs.umass.edu/%7Eemery/talks/OOPSLA-2002.ppt>.
*OOPSLA 2005: Quantifying the Performance of Garbage Collection vs.
Explicit Memory Management
* with Matthew Hertz. <http://www.cs.umass.edu/%7Ehertz>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel