Calling a function has a certain overhead. Registers must be saved, a new stack frame pushed,… For small functions this overhead is more than the actual implementation of the function!

For those, it is much better if the compiler would copy-paste the implementation directly into the call site. This is what inlining does.

Luckily, the compiler is usually able to do this optimization. Or can it?

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool. This time I’m going to cover inlining. I’m going to share some of guidelines I’ve learned and also going to give you a look into some of memory`s internal code and design.

When I’ve released memory 0.5, a guy on reddit asked how my library compared to Boost.Pool. I provided a feature comparison and also quickly profiled both Boost’s and my implementation. Sadly, Boost.Pool did beat my library - in most cases.

So over the last weeks, I’ve took care of my performance problems and rewrote my implementations. So in version 0.5-1 they are basically still using the same algorithm, but now my library is equal or faster than Boost.Pool.

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned doing them. The first part is an introduction to the different allocation algorithms used here and gives an overview about the profiling results.

Last Tuesday I took a closer look at the Concept TS. This followed a discussion about the power and usefulness of concepts regarding a replacement for TMP (shout-out to @irrequietus and @Manu343726). So after compiling the GCC trunk that has concept support, I’ve specifically looked in a way to use concepts alone for doing arbitrary calculations.

Attention: This is completely pointless. You’ve been warned.

For that, I tried to implement a Prime_number concept that checks whether a given number is a prime number. It should use only concepts and require to do the calculation.

As of version 0.5 my memory library now provides support for system-wide installation and CMake’s find_package().

Because I’ve spent hours of trial and error to come up with it, I’ll document it here. In this post, I will show you how to install your library so that it can be used easily by other projects. In particular, the system will be able to handle multiple installed versions and multiple configurations.

Throughout this post, I’ll be assuming a 3.x CMake version and an already existing CMake project.

I thought the last release has taken a long time, this one took even longer for less changes! But now foonathan/memory is finally released. This time things get low-level to allow a better high-level.

foonathan/memory is a library providing various memory allocators and adapter classes. Those allocators use a new RawAllocator concept that is simpler than STL’s Allocator and allows better control over the allocation aspect. Adapters and traits ensure compatibility with the existing model, allowing usage in STL or other containers.