Closed Groogy closed 11 years ago
If we go all the way with heap allocated memory we can easily implement a debug output where the application prints out it's memory footprint from rbSFML in the window. For instance if the developer is allocating a lot of small images for some special effect he came up with or maybe caching some generated graphics. Then it would start to show here even if he throws away all references and the garbage collector haven't run yet. And it would help him out with finding out that the many allocations of images are the problem and he should start with reusing objects instead. Etc. etc.
Then on the other hand, this can be done without us implementing anything extra and only returning a simple sizeof
operation. But of course it is easier to use if the expected data is already included.
Alright since we have decided to implement that we can track the memory usage of instances in rbSFML for debugging purposes and maybe later even more. We have some stuff to decide on how verbose we have to be. Since we are already planning to implement it we can either limit us to mimic a simple
sizeof
command or go a bit further to make work easier for developers.There are some questions that will arise here. How much should the classes
#memory_usage
method return? There are some clear ones likeSFML::Event
that should only return a simplesizeof( sf::Event )
and then we have border cases like sf::SoundBuffer where we should also return the actual HEAP allocated size. The hardest ones are the one that have most of their memory on the GPU and not on the normal memory that#memory_usage
is supposed to return.I'll write a list here with the special case classes and why I consider them special cases here:
This issue is more or less to discuss... How much information should we output in the
#memory_usage
method?