"Premature optimization" is the wrong warning phrase. I said as much.


In any case, I strongly disagree that people should be (in general) left to decide whether or not to reinvent a wheel. Unless you are exceptionally good, or have very sound evidence that you can do better, existing solutions are almost always the right thing to use.

And yet, in this thread where you moan about it, the first person to use the term goes on to explain why.... so, what was your point again?

While I have had a beef with that phrase for a long while, perhaps the reason this thread was the thread that broke my back is because, as rightly mentioned in this article, memory managers are not something you can just one day realize you need and then add them.
It is a mature optimization, in that if you ever need one, you need one from the very start.

Since the needs of each person vary, it is not in our place to say he does not need a memory manager. And the frank fact is if we say he doesn’t, but later down the road he does, we have done a huge disservice, as there is no recovery from that situation.


Yes, he explained why he said that. And in doing so he suggested that you wait until the memory system proves itself to be a bottleneck (#1), trivialized the gains in performance you could potentially get (#2), and suggested that the problem is higher-level (#3).
#1: Again perpetuating the flawed view many programmers have of the meaning of the phrase. No, you most certainly do not wait until your memory system proves itself to be a bottleneck.
#2: The gains can be huge. Not only in performance but in added debugging.
#3: It certainly could be a higher-level problem. But custom memory managers exist and are widely use for a reason. The simple fact is that improving your overall engine design might actually give you even more of a reason to come up with a custom memory manager. You can add features that help your overall engine design, and again this needs to be something you lay down early in the project, not later.



One of my early game engines was slow partially because I didn’t have a custom memory manager. I didn’t have the ability to exploit certain features that would have been a huge gain to my overall performance, and I had to design around that.
On a later project I realized this problem and one of the first things I did was make a custom memory manager that met the needs of a superior engine design. It proved to be one of the most essential parts of my engine.

That is my point.


L. Spiro

"Memory manager" is a terrible term and I hereby propose that anyone who uses it henceforth in this thread deserves a swift kick in the face.


Writing a wrapper around an existing allocation system - or, better, deploying specialized allocation schemes instead of dumping everything on a general-purpose heap allocator - is a fine and dandy goal. I would go so far as to say that if you aren't mindful of allocation patterns to the point where you are controlling them via smarter allocation schemes, you're doing it wrong (on non-trivial projects at least; don't forget that plenty of games can run on modern hardware without being stupidly optimal).

If you write your own heap allocator in hopes of improving everything, you're also doing it wrong. If you write a heap allocator without first deploying better allocation schemes in general, you're... well, to keep it politically correct, you've got a hell of a lot to learn.


Advocating smarter allocation schemes is good, and I support this. For 99.9% of programmers, this means using existing allocation scheme libraries - which, generally speaking, also get you access to debug instrumentation and inspection tools, which solves basically all of the problem.

Advocating custom heap allocators is bad, and I do not support it in any way, shape, or form - especially when the advocate is working with precisely zero information on the nature of the program and its allocation patterns in the first place.


Yes, a little bit of pre-emptive consideration can save you a lot of pain down the road. But deploying complex allocation strategy frameworks is not always a foregone necessity. If you're writing PacMan or a Zelda clone for the contemporary PC, you have no need to waste your time on such things. If you're working on a mobile device or writing the next Halo, then yeah, you'd be silly not to do some memory planning up front.



Sometimes, the "right tool for the job" means not dropping a bomb on a village just to eradicate a couple of mice.



Carelessly broad generalizations are for people who are incapable of thinking for themselves.

Hand-rolling a general-purpose heap allocator by yourself.

There do exist a few general-purpose heap allocation implementations that are very, very good - and I use them. (dlmalloc comes to mind readily, for instance.)

I should have been clearer: I'm not against replacing heap allocators if there is a need for it (and on many platforms, especially when pushing the limits of the system, there is a definite need). I'm against the average programmer striking out to reinvent that particular wheel, because it's bloody hard and I've seen far more horrifically bad attempts at it than good ones.