it's been a while so. Why is spring so darned slow.

[smoth]

this is a question to the devs about the engine and does not need people speculating.

A while back you guys did some evaluations into the engine. I cannot remember what was said but I would like to know if you guys currently know the major bottlenecks, minor bottlenecks and if there is anything I can do as a content developer to mitigate them?

[zerver]

Is it the graphics that you find slow, and/or the CPU usage that is high?

I suggest disabling all widgets and changing graphics settings to minimum. Then check again.

If you run e.g. BA with the default widgets on, I agree it is horribly slow. Not exactly sure why so many widgets are activated by default.

If it is slow wrt CPU, maybe because the engine got more powerful/configurable?

[smoth]

well is the pathfinder still expensive?

How much does unit piececount effect performance?

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

Why is it the spring graphics are so taxing? As in often halving fps where as I can run many other games just fine(keep in mind I am talking even recent titles).

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

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

These are some of the questions.

[hoijui]

run an 8vs8 BA game at max speed, with some RAI, KAIK and E323AI.
use a map with not too much open field (some mountains are good), and set speed to 10x.
after some time, there will be places where hundreds of units get stuck, all having move orders, and that makes the game very slow, cause theres lots of path-finding done for that, plus the collisions and all.. its this very basic CPU stuff. in general, having a better path finder would help the most. that is planned already. we can not say when it will arrive.
other then that, benchmarking your Lua can not hurt, and is a much easier thing to get better performance, if there are bottlenecks.

[smoth]

Hmm, is there any suggested method for benchmarking gadgets?

[knorke]

well is the pathfinder still expensive?

I would say yes. Once I cheated tons of peewees on a map (like 1000) or so and the fps was ok. Then if you move them, the fps dies, even on flat open maps. The collision between units make it worse I think as that uses cpu too.

lots of patrolling fighters also make any game into a fps lag fest.
in lobby someone said it is because of their LOS being updated so often even though planes already use a simplified LOS.

There was a thread where someone (Argh?) made a superhigh polygon sphere and claimed it did not make a difference in fps compared to a low polygon unit. Or something.

In really old xta, the vulcan/buzzsaw cannons would always cause lag. I dont know if it was because of too many projectiles, terrain deformation or something else but it does not do that anymore.

Some mods have other fps even on same settings. ie xta gets much higher fps than ca even if there are only 2 coms on the map and i am not looking at them. I guess it must be some LuaUI.
Some widgets really can slow down the game even if it just a fancier playerlist. (something one would not expect to have such an impact on fps) I would not say Lua is always slow but maybe most widgets are not optimized for fps.

[smoth]

yes poly count doesn't make an impact but is it the pathfinder or the animations moving all those pieces.

[zerver]

I would not say Lua is always slow but maybe most widgets are not optimized for fps.

Probably both. LUA is faster than much of the competition but like any other interpreted high level language suffers from a super high function calls per instruction ratio. Even with branch prediction and other optimizations, modern processors just hate that.

[FLOZi]

<semi-offtopic>Wasn't lurker working on getting luaJIT for luaUI?</semi-offtopic>

<totally-offtopic>This is the kind of thread/discussion that should go in new content/engine dev discussion forum, as well as the simpler questions</totally-offtopic>

[zwzsg]

No matter how awesome the language is, a bad programmer can still write poor algorithms eating away all the CPU.

[Licho]

Not to mention lua is not awesome nor fast :)

[AF]

The turtle will always beat the starship enterprise at warp 9.9 in the marathon if the turtle only has to put one forward while the enterprise crosses half the galaxy.

[Argh]

Ask programmers to talk about benchmarks, and you'll soon be hearing aphorisms and lies.

Look... using BA as a benchmark is utterly wrong.

If you're going to get meaningful numbers, use CA. It is a much more representative sample of how the engine is actually being used by the majority of game developers.

1. It uses S3O, not 3DO.
2. It uses extensive LuaRules.
3. It uses fancy Widget technology like LUPS.
4. It has Lua AI to test against.

The results and numbers you guys cite from BA tests don't even slightly resemble what I see with P.U.R.E., and I'm pretty sure it's because you're not testing the things we're actually using.

What I see atm is:

1. Large use of CPU time on drawing, even when we're well past 60 FPS. Draw won't throttle itself, and competes with sim for time.

2. Sim has huge periodic use of CPU during SlowUpdates, even when everything on the map is a static Unit that isn't doing anything.

I mean, seriously people- a few hundred trees (they're "buildings" in P.U.R.E.) is a significant cost during a slowUpdate.

WTF? They aren't doing anything, checking anything, pathfinding, animating, or doing anything else. Even when they're not on the screen, they're eating performance like crazy. I feel like there are serious optimization problems with Units that are idle atm.

3. Draw costs are very high, even when the camera's not pointed at any geometry.

4. So far as I can determine, it's not Widgets or Gadgets causing any of this. The highest-impact Gadget I've got running eats less than 2% of the CPU during it's highest run.

5. There aren't good profiling tools built in to give game designers the ability to give you people a report that we all agree is meaningful and reflects real numbers. It's always possible to dismiss what game designers say because there's no standard of evidence.

This last is important.

I'd like for this to be scientific, where we can all talk meaningfully about it without people like Smoth getting their panties in a knot because I don't have all the sacred numbers and am forced to speculate about what's going on.

We need a standard tool for this, that is game-agnostic and will give us the numbers we all agree actually matter.

[Pxtl]

To be fair, BA does work for benchmarking features of the engine itself instead of the mod Lua - after all, it barely has any.

I mean, maybe you've some Lua function that's running through all those trees? I'm sure you don't, because you're smarter than that, but that kind of possibility needs to be considered.

CA's lua-intensive modding is probably not the best example. A low-Lua, S3O based mod is probably the best for benchmarking... Gundam, then?

[Argh]

CA's using a lot of Lua, but it's battle-tested and we can presume it's as efficient as it can be.

We need to see tests with it, not something where Lua isn't a factor, because if you don't use Lua, you're just building an OTA clone, not using a game engine.

It wouldn't bother me a lot to see multiple games benchmarked, though, just to see some numbers that aren't hogwash.

But frankly, I think we need a standard toolset for this. It should be possible to run a benchmark with any game, that does the same stuff and provides the same numbers.

Then developers have a nice way to either say, "gee, look at X, it's slow and it's not our problem" or "gosh, that test shows us that if the engine's asked to do Y, it's really slow and we should check out why".

As opposed to this kind of thing, where everybody has various reasons to be grumpy, but nobody has the information they need to change the situation.

[Pxtl]

I think KDR proved a half-dozen times that naked Lua-less Spring can be used for distinct, non-TA gameplay, but your point is well-made either way. CA uses a _realistic_ amount of lua and the lua code is trustworthy in that it works well and has been tested to death.

[smoth]

Ca is not near that argh

I appreciate the vote of confidence but I question the efficiency of gundam which is why am investigating this stuff right now.

[Argh]

What do you think would be a good test, Smoth? I figured CA would be the most representative, but S'44 is also in that range.

I don't think KP works, and I'm not bothering to nominate P.U.R.E., as certain aspects of it are currently torn apart again, and the last time I wasted a day packaging up a World Builder map for the devs, nobody bothered to actually test stuff with it.

[Tobi]

Use a profiler, run it on a few spring demos from different games, combine data and analyze results.

Not that this is really easy, but just saying that it's not necessarily needed to base any kind of benchmark on a single game only.

[Argh]

Is there any way we can have a profiler built in, so that running Spring with a flag set gives us a meaningful report that we can all agree has meaning?

IIRC, the last time I looked at profilers that were external, they take a fairly large amount of setup to know what you've been profiling.

Moreover, aren't they codebase-dependent to some degree?

Basically, I am not keen on figuring out how to do this, if it's just going to cause more arguments about whether the numbers are "valid".

And in addition, it won't give us all the numbers we need, to make intelligent optimization decisions:

1. It won't tell us how many triangles the engine was rendering.

2. It won't tell us how many vertexes are being processed.

3. It won't tell us how many textures were sent to the GPU (this is one of the big reasons BA is not a valid test).

4. It won't break down Lua by Gadget / Widget, letting us know what's eating a lot on that end, or where we're getting burst activity that's causing a problem.

5. It won't tell us how many things were executing an animation step.

6. It won't tell us how many things were being rendered on any given pass.

7. It won't tell us how many Units the engine thinks it's handling.

In short, I don't think it will give us useful numbers, even if we all agree on a given profiler (ha) and on the meaning of the numbers derived (double ha).