4 ms·

Before considering changing the allocator to improve performances, review the way you consume memory.

yason 17y ago
While you can try to not do anything stupid with regard to your allocations, there's often very little you can do. If you try to implement your own allocator you're often just wasting time. You either use the best allocator library you can find or end up having a half-baked allocator of your own on top of a poor default allocator library. A good allocator is essential for performance. Writing a good allocator is not trivial so your home-made allocator is likely to be slower, consume more memory than an optimized generic allocator, and exhibit all kinds of weird random hiccups when a critical malloc() or free() happens exactly when the library can't avoid housekeeping anymore and goes into a costly cleanup mode. An optimized allocator has loads of knowhow in guarding against these corner cases, both algorithmically and by having empirical special cases to help amortize the cost of maintenance. I've seen many programs that couldn't possibly have predicted their allocations any better but were still stuck until an alternate allocator was bolted in and the juices began to flow smoothly again. I expect a modern allocator to adapt to various use cases, from managing large variable-size chunks of memory to intelligently pooling a thousands and thousands of small objects of one size. And much more. Automatically.
- shin_lao 17y ago
  Most software I audited overuse dynamic memory. Before considering changing the allocator, consider allocating less (zero copy, use of the stack, in place allocation, etc.).
- ajross 17y ago
  I think the point was that a "home made" allocator is going to be able to exploit structure in the data that won't be visible to a general purpose malloc -- c.f. the pool allocators used in Apache, which know a priori that they'll be freeing everything at the end of the request. Likewise objects with the same lifetimes can live in the same block, etc...

yason 17y ago

While you can try to not do anything stupid with regard to your allocations, there's often very little you can do. If you try to implement your own allocator you're often just wasting time. You either use the best allocator library you can find or end up having a half-baked allocator of your own on top of a poor default allocator library. A good allocator is essential for performance. Writing a good allocator is not trivial so your home-made allocator is likely to be slower, consume more memory than an optimized generic allocator, and exhibit all kinds of weird random hiccups when a critical malloc() or free() happens exactly when the library can't avoid housekeeping anymore and goes into a costly cleanup mode. An optimized allocator has loads of knowhow in guarding against these corner cases, both algorithmically and by having empirical special cases to help amortize the cost of maintenance. I've seen many programs that couldn't possibly have predicted their allocations any better but were still stuck until an alternate allocator was bolted in and the juices began to flow smoothly again. I expect a modern allocator to adapt to various use cases, from managing large variable-size chunks of memory to intelligently pooling a thousands and thousands of small objects of one size. And much more. Automatically.

shin_lao 17y ago
Most software I audited overuse dynamic memory. Before considering changing the allocator, consider allocating less (zero copy, use of the stack, in place allocation, etc.).
ajross 17y ago
I think the point was that a "home made" allocator is going to be able to exploit structure in the data that won't be visible to a general purpose malloc -- c.f. the pool allocators used in Apache, which know a priori that they'll be freeing everything at the end of the request. Likewise objects with the same lifetimes can live in the same block, etc...