libsdl-org
SDL_malloc num_allocations tracking should be optional
While kicking the tires on SDL_GPU, I noticed that SDL_AddAtomicInt_REAL was near the top of my profiles (7th, to be precise). Most of the calls to this function are from SDL_malloc, where it tracks the amount of memory allocated. This probably indicates that SDL_GPU has high malloc traffic (and it does), but it also seems like it would be an easy small win for performance-sensitive users to not do these atomics on every malloc/free operation, or find a way to make them cheaper. Alternately, you could make them optional so that people like me can turn them off to squeeze out extra performance on underpowered targets like Steam Deck.
To provide concrete numbers, SDL_AddAtomicInt_REAL was 527ms of exclusive execution time in a ~75000ms long capture, so around 0.7% of execution time.
There are a few areas where things like this could be filtered out at build-time. I'd be interested in using it.
In the mean time, is SDL_SetMemoryFunctions() any use?
There are a few areas where things like this could be filtered out at build-time. I'd be interested in using it.
In the mean time, is
SDL_SetMemoryFunctions()any use?
If I understand the code correctly, the atomics are outside the memory function, so it wouldn't help: https://github.com/libsdl-org/SDL/blob/9f170286ba670852afb908327af7a60402bbf96c/src/stdlib/SDL_malloc.c#L6431-L6436
The atomics could be made optional by providing a memory function that does recording and one that doesn't, perhaps.
I see how SDL_SetMemoryFunctions() works now, so yes, that's no help.
I hope this gets looked at when considered for disabling mentioned here
We're going to add an #ifdef around these atomics, so if we ever want to build something that checks for allocation counts, we can, but default it to off. All these are doing is incrementing, so it would need a debugger attached to be useful in any case, atm.
