I noticed that some SDL3 API areas (e.g. IO, processes) make quite heavy use of the relatively new SDL_properties mechanism. Since properties are heap allocted, multi-thread safe and use fine grained locking this is causing a lot of memory allocations and mutex locks vs. a more traditional implementation.

E.g. if I call SDL_IOFromFile, it performs these operations before returning, plus whatever else is involved in the hashtable manipulation (which I didn't instrument).

SDL_malloc
SDL_malloc
SDL_LockMutex
SDL_LockMutex
SDL_free
SDL_LockMutex
SDL_free
SDL_calloc
SDL_malloc
SDL_calloc
SDL_calloc
SDL_calloc
SDL_calloc
SDL_calloc
SDL_calloc
SDL_LockMutex
SDL_malloc

Obviously opening files is a relatively heavyweight operation, but this still feels excessive to me for something which always happens within a single API call on a single thread. (NB: This is using custom heap on my side, and I (after the edit!) didn't instrument the locks required to synchronise access to that, so these should all be from the SDL side.)

I can see that a bag of properties is nice for one-time things like device configuration, and solves some problems neatly, but it would be good if it stayed away from things which happen more than once or twice in a game session.

E.g. for IO, having a fixed-size "file system handle" space a la SDL2 would solve this with much lower overhead. And for SDL_CreateProcessWithProperties, an optional parameters structure could do the same thing?

Thanks for listening!