Possible SFML Optimisations as Suggested by Profiling

[Mikademus]

Since Laurent mentioned in another thread that he was interested in suggestions for possible speed optimisations of the framework I thought we could collect our findings from profiling in this thread.

----------------------------------

Yesterday I profiled our 100+ kloc SFML project using Sample Profiling under VS2010. We have not yet performed instrumental profiling, but will soon. Note that we use the build of SFML2 before the new shapes API were put in. The results were slightly surprising to me.

The #1 bottleneck for SFML performance in our application  was the creation of sf::Shape. Previously, for every frame and for every tile I had several sf::Shape::Rectangle created. I also had numerous sf::Shape::Line created in a loop for a grid drawn to the background. The profiling indicated that actual rendering represented a relatively minute portion of processing time (less than one percent) while creating (and to a lesser extent deallocating) sf::Shapes assumed a whopping 10%. I fixed this by buffering and reusing shapes and sharing them between all possible instances. However, because of the expense, this might be a place where SFML itself could try to optimise costs, f.i. by using pools or internally delaying destruction and reusing objects rather than reconstructing and deallocating them. How this would integrate with the new shape API I don't know, but if nothing else perhaps a note about possible expenses could be added to the documentation.

Other bottlenecks were due to client code. I will return with more findings when I've analysed an instrumentation profiling later.

[Laurent]

Hi

Thanks for sharing your results, but as you may expect I'm not interested in anything that use the old graphics API

And I already know what the main bottlenecks are: it's the number of OpenGL calls involved when rendering many small entities. Typically sprites. One solution would be to batch geometry but it's a complex subject since SFML is very low-level and cannot assume much about what people will do.

So basically what would be interesting to talk about is potential optimization strategies for rendering many small entities. A little knowledge about graphics stuff is of course required, I don't want messages such as "use VBO!!!!"

[Groogy]

Well you could do as DirectX and provide a batch class. More or less so that developers can explicitly say "I want these sprites batched" and then render them in one batch. But of course this is simple to implement yourself.

Though I think you should more or less focus on allowing the possibility to optimize. Not to actually make them yourself. Batching is always possible of course. But maybe prepare so that it is possible to use more advanced optimizations. I myself are of course thinking of allowing to push custom data to the shaders which would for instance let one create the entire particle system on the GPU and so on.

We more or less have to also check, where are SFML bound right now? CPU or GPU? If it's on the CPU we want to put more work on the GPU. But then if someone is using SFML in a way that limits them on the GPU then we want to use the CPU.

 I think it's impossible to come up with a "One solution to rule them all!"
You probably will have to provide different explicit ways to run optimizations on or something like that. Or do as I said, give possibilities to add custom optimizations.

[Mikademus]

Sure, I understand that the old API might seems like a suboptimal aspect to base suggestions for optimisations on. However, I brought it up for two primary reasons:

1) I assume that you've reused substantial amounts of the old system in the new architecture. Also, the creation expense would come from SFML-side calculations or initialisation, or from creating OGL resources, and these things should still be similar and incur a comparable cost.

2) The new API seems to present a similar usage affordance (how the code and classes suggests/invites to be used). The old static construction methods screamed to be inlined inside Draw() calls, which is why such a hefty cost from that was surprising to me. Therefore, there is a strong likelihood that the new API will be used in a similar way with the same overhead, and which is why it might still be a good place to consider for optimisations and documentation notes.

As for the main focus of SFML bottleneck being sprite rendering, in my use case that wasn't so: only about 1% time was spent actually rendering. However, our game only uses hundreds of sprites on-screen on any single time and I realise that for thousands-of-sprites games and with dense particle systems things will of course be different.

I will upgrade to the stable SFML2 when it is released and will of course post profiling results here if you're interested.

[Laurent]

1) I assume that you've reused substantial amounts of the old system in the new architecture. Also, the creation expense would come from SFML-side calculations or initialisation, or from creating OGL resources, and these things should still be similar and incur a comparable cost.

Nop, in the new API shapes are more specialized entities so that you can change the radius of a circle, the size of a rectangle, etc. and you don't need to create them from scratch at every frame.
And the implementation has changed a lot.

2) The new API seems to present a similar usage affordance (how the code and classes suggests/invites to be used). The old static construction methods screamed to be inlined inside Draw() calls, which is why such a hefty cost from that was surprising to me. Therefore, there is a strong likelihood that the new API will be used in a similar way with the same overhead, and which is why it might still be a good place to consider for optimisations and documentation notes.

No more invitation to inline the construction inside the Draw call directly. The new API screams to create the shapes as real entities, and to update / use them instead of creating new ones every time

[Mikademus]

"No more invitation to inline the construction inside the Draw call directly. The new API screams to create the shapes as real entities, and to update / use them instead of creating new ones every time"

That's good to hear and may help new code to avoid some inefficiencies.

Also a nice little reminder for myself that the design of an API can cause inefficiencies or efficiencies not in the way it is works per se, but in how it invites to be employed by the client.