Spring's performance MKII

[smoth]

Because the prior thread was derailed I am starting a brand new one. These questions are only to people who are engine devs as in have direct commit access to the svn. The only others who can respond who are an exception are KDR, lurker, aegis, spliff and BD and flozi as I am aware that they have an indepth understanding of the engine.

I am asking these questions because I need answers as I am looking into areas I can improve the performance of my game.

I will start with a few questions:

Is the pathfinder still expensive?
People observe that in the debug graph the pathfinder seems to peak during mass unit movement.

How much does unit piececount effect performance?
JK you once told me that you had run some tests and found out that piece count does indeed hurt performance. What was the numbers on that again in terms of fps lost?

If I reclaim features does that cause a pathfinder update? if so, is this update expensive?
I am looking at doing some feature heavy maps, with so many features the player will be forced to bulldoze or reclaim to clear passage ways. The issues is that I am unsure of how the update process is done and would like some insight on it.

Does the mapsize alone(due to pathfinder updates etc) eat performance?
Large maps seem to have a low fps, I am usure if this is due to the amount of tiles per map or if it has to do with the map being large and spring has to update for that whole area.

How accurate is the debug graph or is it really more of a crude performance calculation?
I don't even understand how this thing works but I have read it many times and always get confused as to how the pathfinder eats soo much process time

These questions are for devs. If you are not in the group of people listed at the top of this thread, and respond, derail this thread and I will simply make another one. I am looking for some specific answers from people who actually understand this stuff.

[jK]

Is the pathfinder still expensive?

From my profiling pathing never becomes a real bottleneck, just LOS update can become one (it is strictly linked with unit movement).

How much does unit piececount effect performance?

Still unchanged.

If I reclaim features does that cause a pathfinder update? if so, is this update expensive?

Pathfinder isn't that smart, it doesn't update existing paths, instead it just calculates it once (when the unit requests it/starts moving) and then caches it until it reached a specific `waypoint` and then it request the next path and so over.

Does the mapsize alone(due to pathfinder updates etc) eat performance?

My profiling couldn't show such a correlation, I assume it is just subjective. So you need to move the camera a lot more often and there is much more space for units -> higher unit counts.
Only the LOS texture update is mapsize dependent, still it should never eat >14% cpu usage (with very small maps <4%).

How accurate is the debug graph or is it really more of a crude performance calculation?

The profiler is quite user-unfriendly and only for devs who can check the code, so most items are subitems of others (that's why it doesn't sum to 100%) and you need to know their `tree` which isn't displayed in the graph.

[smoth]

instead it just calculates it once (when the unit requests it/starts moving) and then caches it until it reached a specific `waypoint` and then it request the next path and so over.

so what is with the path building thing on spring load, is that now unused?

Considering this quote as well, does that mean terrain deformation only realy causes slowdown on the creation of the new paths?

[lurker]

Smoth, you failed to make a distinction between updating the pathing information for the map and updating individual unit paths, and jK was talking about the latter.

[SpliFF]

Thanks for including me in your list smoth, but I really only know some specific parts of the engine (pretty much the model loader and some parts of the rendering pipeline).

jK, could you elaborate on your observations on piece counts?

I wouldn't have thought we'd see a large impact since:

* The unit radius is used to filter the piece collision volumes and LOS out of area searches.
* Moving a piece should only involve some relatively simple COB and matrix operations. Though I suppose these add up when we're talking thousands of units.

What sort of performance figures were you seeing? How did you test?

I assume this is relevant to smoths question.

[Beherith]

If anyone wants to test spring with a profiler, I built the latest GIT revision in msvc, so it has a .pdb file next to it. This allows my favorite free profiler, Very Sleepy to translate all adresses, and shows the source with performance counters next to it.

Link to built spring:
http://beherith.eat-peet.net/stuff/sprtest.7z

[slogic]

I just realized about some very irritating issue faulty considering it was performance related.

On every machine with Intel graphics (may be not only under Intel) when i'm holding arrow keys the screen moves with hops (not smoothly). I thought this is because the game eats too much CPU at some time. But then switched to middle mouse key movement and could move the camera without any glitches.

I'm playing in windowed mode under Windows.

Has anybody noticed this?

[Pxtl]

I hope this isn't horning in too much, but because it's a relevant question related to one of Smoth's questions (and a few design ideas I have):

In the vein of piececount, is there any performance savings with invisible pieces? Or is a 200-piece unit that is only showing 12 pieces really a 200-piece unit? I realize that the synch and update looks still treat it like it's 100% there, but what about the rendering?

[jK]

Smoth, you failed to make a distinction between updating the pathing information for the map and updating individual unit paths, and jK was talking about the latter.

didn't profiled the other one, nor do I know what it does exactly.

jK, could you elaborate on your observations on piece counts?

The problem is that the engine doesn't cache the per-piece matrices, so each time the model is rendered (or the synced side requests the piece pos) it has to go the whole hierarchy and uses slow glTranslate & glRotate, instead of buffering the matrix in a VBO/UniformBuffer or sending it in a VertexAttribute (:= Pseudo Instancing).

when i'm holding arrow keys the screen moves with hops (not smoothly)

Engine bug. Will get fixed with my next commit wave.

In the vein of piececount, is there any performance savings with invisible pieces? Or is a 200-piece unit that is only showing 12 pieces really a 200-piece unit? I realize that the synch and update looks still treat it like it's 100% there, but what about the rendering?

Only if it is a leaf in the model hierarchy. Else it doesn't know if a child-piece may be visible, so it can't skip the matrix transformations for hidden pieces with children. Also empty pieces are hidden by default, so they are optimized when being leafs in the tree.

[Pxtl]

Thanks! Of course, the processor load for hidden parts is probably more important than the GFX load, but it's still good to know what's there and what isn't.

[slogic]

when i'm holding arrow keys the screen moves with hops (not smoothly)

Engine bug. Will get fixed with my next commit wave.

Should i create bug report? Do you have time to finish it before 0.82.6 release?

[jK]

already there and commited
http://springrts.com/mantis/view.php?id=2098