Well said.
While it may be true that some memory allocators are lacking, the ones I
use are quite good. I view with great suspicion developers who thinks
they can outsmart the pool allocator. These folks usually add great
complexity while having at best a neutral impact on performance and
robustness. As you point out, they can only optimize for their module,
not globally. Any changes of this type should be carefully tested of
course, but just as importantly backed up by thorough performance data.
Joe Wilson wrote:
--- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
Our studies to date indicate that SQLite neither leaks nor fragments
memory. Preventing leaks is relatively easy. Preventing memory
fragmentation less so. Yet we are not seeing memory fragmentation
as a problem for the workloads we have tested.
Nevertheless, we cannot *prove* that SQLite, in its current form,
will never fragment memory. However, we are working toward a
future release where such a proof will be possible, at least for
certain well-defined operating parameters. We just are not quite
there yet.
Pool allocators can be effective for certain classes of problems
and can exhibit desirable deterministic properties. But a library does
not exist in isolation. You must consider the entire program memory space.
If every library used its own distinct pools then a program that
uses many of such libraries (sqlite, apache portable runtime, GNU STL,
whatever) may ultimately end up with is sub-optimal memory utilization
for the entire program. Space reserved for one library, but not currently
in use might be better put to use by another library's short-lived
operation, for example.
Using the same allocator for the entire program can give it optimization
opportunities that may not necessarily exist with distinct library-specific
memory pools.
An example from Hoard's docs (mostly speed related, as opposed to space):
http://www.cs.umass.edu/~emery/hoard/faqs.html
I'm using the STL but not seeing any performance improvement. Why not?
In order to benefit from Hoard, you have to tell STL to use malloc
instead of its internal custom memory allocator:
typedef list<unsigned int, malloc_alloc> mylist;
For some problems library-specific allocators are very useful.
You have to consider other factors as well.
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
