SFML community forums
Help => Graphics => Topic started by: heishe on August 17, 2011, 07:53:27 pm
-
The following code:
#include <sfml/graphics.hpp>
#include <iostream>
int main()
{
sf::Image i;
int a;
std::cin>>a;
return 0;
}
Lets my application jump from 600 kilobyte memory usage to 13 megabytes (13,000 kb) after the line "sf::Image i". Adding a second image let's it jump only marginally (a few bytes).
Why is that? Is there a memory leak in there somewhere (maybe one of the sub libs you're using to do the loading?)?
I'm running in Release mode, with release libs of sfml. I'm using MSVC2010 and have compiler optimizations on (/O2).
Hardware: Intel i5 2500k, Radeon HD 6870, 4GB (don't remember exact type) Ram.
By the way, I still use sf::Image because I haven;t update to the latest revision yet (I assume it's unnecessary work because all it does is change a couple of names in my code - unless of course sf::Texture has some sick performance improvements which I doubt). [/code]
-
Maybe it's just the cost of OpenGL initialization. Is it the same if you declare a sf::RenderWindow? Or is it really just sf::Image?
-
Don't forget that the sfml code is also linked in which will also increase the size. The increase in size is not so mysterium. There is several things allocated by sfml on init and also by Windows.
It's normal and 13mb is nothing on a computer, don't worry about it.
-
Actually my application bloats in all kinds of places, even though I have no memory leaks (I have very few pointers and those are managed with smart pointers).
Currently it takes about 50mb in ram with just a couple of images loaded and very few actual data in memory (a few order-3-quadtrees (meaning 64 nodes) and 3 or so images for the tilemaps.
This is frustrating mainly because I don't like the fact that there are games like Knytt Stories which run at less than one megabyte in memory while having huge landscapes and lots of soundtrack :P
I'm still researching though what exactly is causing this bloat. Maybe its a bug in Visual Studio 2010 (compiler or linker) or something else alltogether (really just the cause of initializing a couple of things on windows).
-
A question.. Even though you are comparing using a Release version. Are you doing this trough Visual Studio with the Debugger on? That could add more memory use to the exe.
Well those are pretty extreme low numbers but there are a few tricks to them. If you are obsessed with that I think you should look at Elites 2 and especially the post mortem talks.
For instance one thing you can do is to generate the landscape on the run(not create new but calculate them and not store more than on the call stack when needed) and we can also compress any data and decompress when needed. The thing is, if something takes less memory, you sacrifice CPU time for it and vice versa. Just look at console games where they put a whole CPU core to just handle decompression and streaming of data.
Also I am not 100% sure but if you dynamic link a library to an exe the DLL's/Shared Libraries has to be loaded into memory. When it comes to Windows I don't know if it counts the RAM in use by the DLL's into the exe's count? Would it be possible?
And last let's assume that we have a 800x600 with 32bpp window that we render on. That means that we at least must have around ~2mb RAM just to store the pixels of the window... You see the problem?
All that combined should tell you where all that memory is "wasted" on.
-
Currently it takes about 50mb in ram with just a couple of images loaded and very few actual data in memory
I understand that it's a little frustrating. You should try to identify what eats all the memory (images? quad-tree? something else), and then if it still looks weird, provide a simple code that others (with different compilers/OSes) can test.
Also I am not 100% sure but if you dynamic link a library to an exe the DLL's/Shared Libraries has to be loaded into memory. When it comes to Windows I don't know if it counts the RAM in use by the DLL's into the exe's count? Would it be possible?
Yes I think it happens.
And last let's assume that we have a 800x600 with 32bpp window that we render on. That means that we at least must have around ~2mb RAM just to store the pixels of the window... You see the problem?
The back and front buffers are stored in video memory, it doesn't appear in the process manager ;)
-
Yes, I'm actually a little behind on schedule so I pushed the performance-optimizations back for a bit, so it's going to be a few days until I get the debugger going to check which part of the code is causing the bloat (even though it'll probably take me 10 minutes or less, but I have to focus on other things right now).
50mb is really not bad at all as long as the application doesn't incrementally bloat by 20mb every time I load a 4kb image or something, which (I think) isn't happening.