"Maybe I'm a freako, but I find these this article set to be intensely interesting.
In my travels, I've read plenty of miles of code, including more then a few programs that go as far as memory pools, and even writing a real memory allocator for all practical intents and purposes. This ranges from programs simpler then most (non UNIX) users would think trivial, all the way to more "Complex" systems. In fact, I've even spent time spelunking kernel virtual memory and file system code, which can be a truly interesting set of experiences in their own right.
In working on Stargella, I've wondered whether or not using such techniques would be a viable method of improving the games performance, but for this point in time, everything relies on the C library to work wonders where dynamic memory is needed. While I can see potential savings from adapting a more elaborate memory management schema, it's rare that I'm kicking something around, that really warrants the extra time for creating and debugging code for it, over just rolling with the local libc brew. Of course being the code monkey I am, I always keep an open mind for what the future may bring in the way of change.
Although I will use malloc() quite freely in coding, I also look at it like a reload in a CQB situation: if you're reloading, you're not able to engage more threats, and that (at least for me in SAS) is often the slowest element to an aggressive and dynamic advance. On the other hand though, I generally expect the operating system to provide a decent memory allocator for most tasks, rather then a brain damaged one \o/. Ways to minimize the cost of allocating memory however, is something that I always consider a plus.
Hmmm :-)
No comments:
Post a Comment