Coming back full circle - The Mullocator

When I started this blog, one of the projects I talked about was the Mullocator. My own custom malloc library. I put some considerable effort into it, but when I finished it, I didn't do anything with it.
It was basically too complex for a regular style article. I had no idea what to do with it. I think to make it marketable and accepted it would have taken quite a bit more of an effort, then I was willing to invest.

On the other hand since the code has been staling away for about five years, I don't feel like I am throwing out the crown jewels with the trash, when I put the code into my blog. In all likelihood, there is nothing I would be doing with this code otherwise.

Originally I wanted to use the code in MulleEOF eventually. My basic perception was then, that I was going to optimize MulleEOF that much, that I would be limited by memory speed and - malloc speed - the final frontier. That turned out not to be true. MulleEOF is fairly code intensive and malloc speed isn't really the limiting factor, even if you were to go all out and reduce all the Objective-C overhead to C levels... or at least, that is my current way of thinking.

Well that's not exactly true either, malloc speed can be a factor, but I used the "bunch" object allocation approach for a few choice classes, and that worked well enough. So MulleEOF doesn't bottleneck in memory allocation currently.

A preview of the next installments:
I want to start off with a little historic background, as to why I wrote it. Then I want to talk a little about the real word ramifications, that a malloc library faces and must deal with and ways how to test this and how to hook into OS X. Then I will likely write about, how to approach such a task with some general blather about optimizing again. Finally I am just gonna show the code and discuss the pros and cons of the approach.