Custom memory management |
AntTheAlchemist
|
+1 for this idea.
I'm overriding the new and delete operators in C++ to implement my own memory management and even garbage collection, which works great; I don't ever need to deal with a failed memory allocation, since the manager does it for me. I remember the question being raised in the Steam Q&A session being about SDL having its own garbage collection. Bad idea. Garbage collection in C/C++ in my experience works better per-application because only the application knows best what type of memory to free and where to free it and in what priority to "collect the garbage". For instance: I unload non-essential animation sprite objects if there is no other option - something a generic garbage collection cannot do. LodePNG has memory allocation functions which you can override. SDL2 can easily do the same please. |
|||||||||||
|
Custom memory management |
Jared Maddox
Guest
|
Sensible idea. Why don't you write a proof-of-concept? Remember, you'll likely need to set the function hooks before initializing the library, not after.
If your modifications involve adding these tags to the function signature, then don't make that modification. Instead, define an additional function that you call BEFORE the allocator calls, and clear in the actual allocator functions themselves.
And I assume never will, since this is not a "generic allocator" trait. SDL's allocators are direct wrappers of the platform's standard C library routines in pleanty of cases, and thus need to maintain the same function signature (unless the preprocessor macros got replaced). Non-generic allocations should realistically be done either behind the scenes, or in a seperate library. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Custom memory management |
Sik
|
2015-07-12 2:47 GMT-03:00, Jared Maddox:
For the record, I think that splitting allocations like that is how Windows' allocator works (if the allocation is small enough it gets stored into a dedicated pool, otherwise it gets a proper new block in the heap). Note that such a thing can be done behind the scenes since it only relies on the size of the block to figure it out, nothing else. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Custom memory management |
Camilo Bravo Valdés
Guest
|
I actually went and modified these functions to fit my interface and then tried building the library. This way I could locate every call (lots of them, by the way; this wasn't an enjoyable task) and wrote down the file, function name and line number from where the calls were issued (again, I didn't enjoy this). What caught my attention was the fact that (except for logging) SDL doesn't really do anything particularly silly when asking for memory to the system, i.e. the library naturally fits into the "load any stuff you need before entering the computationally intensive part of your application and then don't do anything crazy with memory" approach. At least for a PC (or Mac, whatever), there shouldn't be any issue at all if the application follows a reasonable "flow" --- from what I've read, the general-purpose allocators in these systems do a pretty good job most of the cases. As for mobile devices, the story *could* be different; I'm not really familiar with such environments. My point is: unless one's a control freak and would like to know where did <insert hexadecimal number here> byte came from, I guess it'b be fine to let SDL do what it's been doing all along and, instead, don't be silly and load a texture every frame. |
|||||||||||||
|