Groogy / rbSFML

Ruby bindings to SFML
Other
44 stars 5 forks source link

Classes Memory Footprint #28

Closed Groogy closed 11 years ago

Groogy commented 12 years ago

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 like SFML::Event that should only return a simple sizeof( 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?

Groogy commented 12 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.