Engine performance in battlescape and ways to improve it about openapoc

[JonnyH]

Is the 50% "rendering" actually in the renderer? I remember the iterators for the actual TileObject loop in draw() being a surprisingly large amount of the profile time in my quick msvc tests.

If it is in the renderer - assuming it's using gles30_v2 - which is the fastest and best on a new enough GPU - how much time is spend in flush() compared to the SpriteDrawMachine::draw() calls?

[Istrebitel]

no, render is not mostly the renderer, it's our classes, and when you dig further it's some "allocation" and "deallocation" (I don't know what it means, but that's what you get when you try to go down the tree)

[Istrebitel]

and this issue was less of a complaint about renderer performance, and more of a question, should I rework the logic to allow multithreading in places where it seems there's not much load anyway?

[steveschnepp]

Multithreading is magic indeed.

Yet its magic is only in the beginning, as it only scales on as much cores you have, which usually is only a 4-8x speedup (which is still nice), but at the expense of hogging the entire CPU :)

Moreover, once you painfully enable a part to be multi-threaded, you'll bear the cost of it forever (shared data, locks, ...).

Change in algorithm such as "pooling" in this case which seems to be "alloc/dealloc" driven, might have much more dramatic improvements.

[steveschnepp]

And HUGE 👍 👍 👍 for your work!