quite true, one extra de-reference per access, i believe. hardly anything to write home about, unless you do a couple million or billion per frame unnecessarily.
my same exact question. from the video that inspired the post, it seems as though newing and deleting things like entities, dropped objects, and projectiles was something that games in general were commonly doing on the fly as needed. which struck me as inefficient and error prone.
games taking over memory management when asset size > ram makes much more sense. its what any good software engineer would do.
If you are allocating a scratch buffer every frame of the same size then just allocate once, at start up, and just reuse it.
i'm saying - that's what i would do.
well, fortunately for me, its not that hard to determine required data structure sizes at compile time. caveman has taken about 2-3 man-years to make. MAXPLAYERS, MAXTARGETS, and MAXPROJECILES have never changed since first being defined. occasionally i'll up MAXTEXTURES from 300 to 400 etc, as the number of assets grows. but that's about it. and i could have simply declared all those really big, then just right-sized them once before release.
The pains of heap memory allocation are usually associated with malloc, not with the heap directly. As you said, it's the allocations that are slow, not the references. This is why most game engines only allocate sparingly, in large chunks, then partition those chunks with some custom allocator. Any engine littered with new or malloc is likely not a very performant engine.
A custom stack allocated on the heap is little different than using the stack directly, or a custom stack on the data segment. You're making like, an extra pointer dereference per allocation/deallocation. That's nothing.
EDIT: On further thought, it's not even that. Incrementing a heap-stack pointer is functionally equivalent to incrementing the normal stack pointer. No extra dereference needed.
sometimes i think we need a term similar to "premature-optimization" to address "premature-over-engineering" - adding capabilities you don't KNOW you'll need, or adding capabilities before you know you'll need them. to me it almost smacks of "throwing code" at problems that may or may not exist. since the requirement is only anticipated, and not actual, the actual requirement details must be anticipated, and are not necessarily fully known already. so one is sort of guessing at a solution ahead of time (a form of throwing code at the problem).
We do have that -- it's called the YAGNI principle, or You Ain't Gonna Need It. See also, "Write Games, not Engines". YAGNI holds that it's better to not implement something until you have an actual need for it because you likely don't understand the requirements and ramifications of that which you don't yet have a pressing need for. Doing so is like trying to design a bridge for a site you haven't seen and have incomplete information on -- you either end up with a design that falls short of requirements, or is very general and likely over-engineered. In either case, effort is wasted and whatever work can be salvaged is not the elegant fit that it should be.
That said, I don't believe the principle applies to your allocation situation in my opinion, and you should also keep in mind that premature-pessimization and premature-under-engineering are also a thing, and can also result in wasted effort and lost opportunity.
I like the analogy of writing code as taking a journey -- You must deal with what's right in front of you most immediately, but you also know that you're headed somewhere over the horizon. You know the most about what's nearest, but you know something of the challenges you will face stretching out to the horizon, even if all you can make out is the general shape and lay of the land -- but you know nothing of what's over the horizon. YAGNI says "It's best not to bet at what's over the horizon", but it doesn't say "Ignore everything that's not immediately in front of you." either, because that would have you building solutions that will likely fall short of requirements that could be reasonably foreseen.
All of that said, I'm not attempting to convince you to change what you have done -- if it works, and continues to work for you, then who is anyone to say? But I am (and I think the rest of us here are) trying to shoot down your misconception that static allocations are beneficial in any way -- they are exactly (or at least approaching exactly-enough to not matter) the same as a single dynamic allocation with same lifetime, but also potentially less flexible. They are no more efficient and only differently complex, not less so.
Games do avoid dynamic allocations, but the why and the how are important. The why is because frequent allocation/deallocation cost cycles, the culprit is not dynamic allocation itself, but simply the quanitity of allocations. The why leads directly to How the industry resolves the problem -- fewer allocations, not static allocations.
Not using the heap as a defensive strategy against bad coding doesn't seem like valid thinking to me.
That not being the main reason , though pretty reasonable reason. If you do not free memory to the very OS, you can implement :
1- pooling
2- cache rapid friendship
3- reordering in memory layout
4- reindexing
C# hiddenly implement those, that is how much those mentions are benefitial at runtime
Well I'm glad there's at least one coder out there who doesn't make mistakes. You must rake in a fortune to not have any bugs at all!
oh, i still make careless errors - its human nature. but they usually are of the "typo that still compiles" form (stegomastodon_atk_wav=119, not 120), or the result of an API i didn't document thoroughly enough, then use it a year later and forget exactly how it works. but when the code base is pretty stable, and built from components used in many games over many years, you're just doing the same sorts of things over and over with the same sorts of components, so bugs are rare, and usually due to careless errors brought about by haste, due to its all being "old hat".
the last memory related error i had was poor API documentation. Increasing chunk cache size requires additional ground meshes for the additional chunks. i increased chunk size, but didn't assign additional mesh space in the meshes database. as a result, it used the assigned mesh memory for as many chunks as it could, and didn't draw ground meshes for the rest - pretty easy to catch in testing. granted, i could write "safer code" that checked for this condition, but this is a condition that should not occur, so once the code is working right, the check is a waste.
while fixing that, i found a related "typo that compiles" bug. max_qauds_per_ground_mesh was defined as chunksize, not (chunksize/quadsize)*(chunksize/quadsize). this would result in vb's and IB's that were too small. however, this memory is allocated sequentially, so directx had no problems until the mesh memory was used up, and then it simply wouldn't draw ground meshes. this one i hadn't caught yet in testing, as apparently,the cache had never been stressed enough to run out of mesh memory, even with undersized mesh allocations. as testing progressed, i got to the point where i would stress the cache to 100% miss level.
but for me, memory related errors are pretty rare. pretty much everything is in an array[MAXSIZE] and gets accessed via for i=0 i<MAXSIZE i++, so no range check errors. variable size assets are loaded all at once onto the heap sequentially at programs startup, and released at program shutdown. the only other use of the heap i make is a temporary allocation of a 1meg buffer to read in a savegame file for a crc check. the buffer is released at the end of the crc_check function.
Not using the heap as a defensive strategy against bad coding doesn't seem like valid thinking to me.
That not being the main reason , though pretty reasonable reason. If you do not free memory to the very OS, you can implement :
1- pooling
2- cache rapid friendship
3- reordering in memory layout
4- reindexing
C# hiddenly implement those, that is how much those mentions are benefitial at runtime
Not using the heap as a defensive strategy against bad coding doesn't seem like valid thinking to me.
That not being the main reason , though pretty reasonable reason. If you do not free memory to the very OS, you can implement :
1- pooling
2- cache rapid friendship
3- reordering in memory layout
4- reindexing
C# hiddenly implement those, that is how much those mentions are benefitial at runtime
Could you explain why you think you can do those things with static but not dynamic memory? Seems unrelated to me.
How one uses memory is a different issue.
Using stack memory as much as possible is for sure desired. I mentioned the upper as the dynamic memory usage, when it is not safe to create an instance on the stack anymore.
One should then declare and instantiate up front as much as possible, and have runtime created objects to come really rare. Not only becouse of the error security, but becouse of many other benefits.
