[SOLVED] High CPU consumption (SFML 2.0 in MacOSX)

[jjjaime]

I've just started playing with this framework and it looks clean and simple. The default application created with XCode template for SFML 2.0 includes just a background image and music. It is a fairly simple app.

However, the window.isOpen() loop is executing continually, updating the window, even though the window has not change at all. Is this a correct approach? The CPU consumption is too high for such an application:
- Window Server process: 20%
- SFMLApp: 16%
- coreaudiod: 7%

It is about 43% of CPU consumption (e.g. Google Chrome is consuming about 1.6% for each tab).

I've also modified the previous app to include a sprite moving with a key stroke. To about updating the window when there was no change in the scene, I've added a isDirty bool variable. It made things even worse because the window.isOpen() loop is executing continually and reachs about 100% of CPU.

After changing the code a bit to sleep (100 ms) when isDirty was false, the CPU consumption was more acceptable:
- Window Server process: 0.8%
- SFMLApp: 2.7%
- coreaudiod: 7%

What is the correct approach to handle the event loop? I've seen that all the tutorials follow the same pattern but I don't think it's very efficient. Perhaps a callback approach could improve this performance issues.

Is it normal to redraw the whole window?

Why does the audio reach 7% of CPU even though there is no more music?

[Laurent]

There's clearly no need to refresh the window at 1000 FPS. So the most common way to lower the CPU consumption is to sleep between two frames, and the cleanest way to do it is to enable vertical synchronization.

window.setVerticalSyncEnabled(true);

You can also limit the framerate to a known value

window.setFramerateLimit(60);

[jjjaime]

Thanks Laurent.
Using either setVerticalSyncEnabled or setFramerateLimit, the rate limit is set to 60. With this approach, the CPU is reduced considerably:
- Window Server process: 5%
- SFMLApp: 5%
- coreaudiod: 9%

However I consider it's still too high for a frozen image that does not require any update.

What I've also confirmed is that using the isDirty bool trick to know when to update the view (window.display()) is even much worse. Using isDirty, setVerticalSyncEnabled/setFramerateLimit do not take effect and the frame rate reaches almost 10000 fps. The window might not be refresh with this frequency, but the frequency of the event loop is too high and the CPU reaches 100%. I guess that there's a direct link between window.display() and the frameratelimit. Is it correct?

Is there a chance to avoid updating the window when there's no change to render? Or to update a fragment of the window?

It's also very high the CPU used by the audio, isn't it? As I said, the CPU usage is constant although the music has stopped playing.

[Laurent]

SFML is made for real-time applications/games, where everything is constantly refreshed. If you're rather developing a "static" desktop app, you should rather use a GUI library like Qt or wxWidgets.

Regarding the audio, I have no idea.

[jjjaime]

I don't want to build an app GUI with SFML. I agree that SFML does not target it. However SFML should not target only games (it's not the project description: "simple and fast multimedia library")

However, if you build a turn-based game, it is possible that the interface is frozen during game AI or while user is thinking. Repainting something that has not changed is inefficient. If your game has a lot of AI, then perhaps you are dedicating some valuable resources to repainting when they are not actually necessary. I understand that this is not a stopper for majority of "games", but I'd say that it should be convenient to include this feature.

Imagine that you build an application that plays music/radio while rendering some beautiful photos or 3D animations. Perhaps the user could use this app most of the time in background mode, and the app would use a lot of CPU when the game does not require rendering (is in background). It could also happen that users hide their games in background during work time 

Anyway, I don't have any special idea to build with SFML yet. I'm just interested in animation and was looking into this library. My first impression is good although I miss that feature.

[eXpl0it3r]

You can decide by your own how often the window is re drawn, just use your own version of setFramerateLimit.
Besides that I get about 1% with nothing going on in the application at 60fps, so idk where you lose the processor time...

[jjjaime]

I'm afraid that the main performance problem is the music. With music enabled, the coreaudiod process uses 9%. Disabling music, this process uses insignificant CPU and the app uses half CPU. Perhaps it is a problem related with my laptop configuration.

[binary1248]

I don't know why people always get alarmed when the "laymans task manager" says that a certain application is using up "a lot of processor time". It is a well known fact that when processors have nothing to do they clock down to a more energy efficient frequency. For some reason some (or maybe even most) task managers don't take this into account and report that some little application is using 99% of the 500 MHz the processor is running at while if it were at 3GHz it would only take up 16%. This is made worse by the fact that Apple needs something to market and has a more conservative power management scheme that keeps clock speeds as low as possible to impress Mac users by the "long battery life" although their system is totally idle (I know of such people from first hand experience so you can't blame me for whining ). This doesn't even take into account that processor usage often doesn't consider multi-core processors, needless to say multi-core processors that run at different clocks.

Unless you have problems running other applications at the same time as your SFML application, or you know that SFML is REALLY taking up cycles 90% of the time when your CPU is at max clock don't worry too much about SFML taking up too much CPU time.

Disclaimer: This was not intended as a flame. Just a statement of an observation I have made over the last months regarding similar posts. Take it with a pinch of salt, or if that isn't enough just ignore it.

[jjjaime]

In this case, I disagree with you. I haven't said that the CPU was idle. Other programs were already opened (e.g. XCode4, many tabs of Chrome, ...). I've just compared the low CPU usages of those processes, that actually are doing much more than the SFML basic application (generated with the XCode template and modified to include some performance improvements).

If Chrome process ranges from 1.4 to 2.3 %CPU, why the sound process ranges from 9 to 10 %CPU  with and without music? For me, that's actually a performance problem. Finally, with some tuning, I could get reasonable values for the rest of the application, except the music part.

[jjjaime]

I close this post because the main part of the problem (except the music part) was already solved.

[eXpl0it3r]

I'm afraid that the main performance problem is the music. With music enabled, the coreaudiod process uses 9%. Disabling music, this process uses insignificant CPU and the app uses half CPU. Perhaps it is a problem related with my laptop configuration.

Well that's certainly no a problem with SFML, since SFML uses other libraries for playback.
What format are you using to play the sound? How do other music application handle the CPU? Is your soundcard driver uptodate?

[jjjaime]

The music file is nice_music.ogg (the one provided by the SFML template for XCode). However, I've tested the same with other file formats: mp3 is not supported and wav offers the same bad results.

My tests have been done with a MacBook Pro, the system is up-to-date and I'm not sure if it's a driver problem. The tests have been done by generating an archive file (in XCode), that creates the app (I guess with all the possible optimizations).

Googling with coreaudiod, it looks like there's a problem with this process (that it was even worse in the past). So I guess SFML is not to blame.