So after "playing" a chicken game and watching quite a few, I noticed that my FPS triples when I do /luaui disable. Clearly something is rather wrong with that as a test with BA shows that I gets only ~10% more FPS without luaui. Now, as always, the slogan is "why don't you do it"? Well, I would like to try my hand at looking at the code, but I've no idea how to go about optimizing for speed or even finding the trouble spots. I know about these: /luarules profile /luarules uprofile Widget Profiler widget However, luaui disable doesn't affect gadgets so I should only be looking at the widget profiler. But nothing stands out to me as overtly wrong. In fact, the highest is Chilli framework (at only ~12%) which cannot be disabled. And disabling all the ChilliUI stuff doesn't help my framerate nearly as much as a /luaui disable. So my request to any dev with a lot of time to kill: I need a crash course in speed hacks and detecting where stuff is using lots of CPU. Floundering around with nothing but my brain isn't working and I've no idea where to start with internet materials. (lots of theoretical stuff about big O, not so hot on practicals)
+0 / -0
|
The practicable of optimization basically comes down to measurement. Unless an algorithm is doing something totally bogus (such as sorting by randomizing elements and then seeing if they are sorted), it could be the most efficient method for that application. Since you brought up profiling, it seems you are already on the right track. Incidentally, a major caveat with asymptotic analysis (ex. Big O/ThetaOmega notation) is that it is meant to be used with large data sets, like sorting 1,000,000 elements in a list. When dealing with only a few hundred elements and operations on them, the lower-order terms and coefficients that asymptotic analysis discards tend to become relevant. At that level it is better to simply count the costs directly. Of course, it is best to measure, though if there is an easy analytic choice between algorithms, go with the faster one to start.
+0 / -0
|
LUA UI surely eats some CPU power but main problem is IMO Spring engine itself, AFAIK, there are only 4 developers now and Spring is very demanding and buggy so games with many units are unplayable and even on very start, i get only 60FPS, in endgame in teams (10v10 for example) it gets VERY laggy and you cant enjoy game like that.
+0 / -0
|
There is this page http://springrts.com/wiki/Lua_Performancebut it is more about small saving by writing loops differently etc. jK once wrote how some Lua practices can "kill the pixelfillrate of gfx card" (cant find post atm) If that happend the fps dropped from 50+ to zero. That was about a fog effect, maybe other wupdgets have similiar effect? quote:
i get only 60FPS, in endgame in teams (10v10 for example) it gets VERY laggy and you cant enjoy game like that. |
That is really just games/admins fault though. Some years ago computers were weaker and 5v5 was the limit of what was playable. With time computers got faster but instead of enjoying to be able to play with smooth FPS now, the game sizes increased. In 2 years computers will be fast enough for 10v10, but then game sizes will once again have increased.
+0 / -0
|
Disable the edge extensions and unit selection effects (halo, shapes etc..). LUPS can be a problem for some computers.
+0 / -0
|
Yeah, all those things are disabled. I experimented a bit more and noticed that disabling show all commands (or setting to show only on shift) also helps FPS alot when there's tons of units. It accounts for about 1/3 of the FPS gain when luaui is disabled.
+0 / -0
|
I suspect that stuff such as dynamic_avoidance might be ultra expensive since it keeps polling all own units for all nearby units
+0 / -0
|
Defaults to off, requires knowing f11 to enable.
+0 / -0
|
That one is off too. But enough about me. I just want general tips and tricks for hunting down and reducing CPU bottlenecks. To the devs, how do you do it?
+0 / -0
|
I like to remove pairs and ipairs (especially ipairs). Reduce engine calls. Store hidden Chili elements instead of destroying and recreating them. In general rarely create Chili elements.
+0 / -0
|
  jseah: Does having "Show All Commands" set to show only on shift help?
+0 / -0
|
GoogleFrog: From a testing I did some time ago creating lua tables is also very expensive (takes 60x more time compared to a typical lua instruction) and should be avoided where possible, in many cases you can reuse tables or just avoid creating empty tables that are not going to get used. For example GiveOrderXYZ functions accept number instead of options table, so you can use 0 instead of {}. This also avoids table parsing on the engine side.
+0 / -0
|
The most expensive thing in LUAUI is Chili Framework. Its the top CPU user that you can see when you enable widget profiler. Even the most complicated gadget (like OD gadget, ShieldLink) only take like 4% CPU when super busy while Chili Framework will take 21% while idle. Other things to consider is the LUA garbage collector. I heard jK said ZK's lua might produce like 10Mb of junk each second (the main point is: LUA garbage collector is working hard). Recently jK commited (in Spring) a manually controlled (manually tuned) LUA garbage collector, and jK mentioned that if LUA gc is like a callin then (LUA gc can be profiled and it) took like 45% of entire LUA cpu usage. When LUA gc is disabled then Chili Framework will only take 10% (which is a considerable drop from 21% during idle/at-game-start). So other issue that take CPU usage might be the "invisible" stuff like garbage collecting that clean stuff up in background which is out of our control (unless we actively recycle table and variable IMO). quote:
I suspect that stuff such as dynamic_avoidance might be ultra expensive since it keeps polling all own units for all nearby units |
Its okay. Even tho the widget is realllly long, when you look at widget profiler it take less than 1% (which is lower than stuff like icon drawer). All widget that do not Draw stuff usually take really low CPU even when its complicated IMO.
+0 / -0
|
Then again, high performance drop by the Garbage Collector may be caused by the work it has to do to find and delete needlessly created tables which I mentioned in my previous post. :)
+0 / -0
|
I totally agree. I saw lots of gadget recreate new table instead of reseting index back to 1 and do a rewrite. (not sure what the best to do... really not sure. For example: chunkUpdateList[] in terrain_texture_handler.lua in DrawWorld(). Is it best to leave a stuffed table un-empty?)
+0 / -0
|
Sometimes resetting table to {} just has to be faster than finding and setting each element in that table to nil. quote:
I saw lots of gadget recreate new table instead of reseting index back to 1 and do a rewrite (not sure what to do... really not sure) |
But wouldn't that show up under impossible-to-disable LuaRules load?
+0 / -0
|
|
|
For tables with lost of elements clearing them to reuse them is too complex and probably will cost more performance than it is worth. What I mean is tables with 0 or 1 or 2 or 3 elements which are for example used as function arguments like in functions like GiveOrderXYZ. There is really no need to create new table with single element each time you call the function.
+0 / -0
|
@Rafal[0K], I'm surprised that creation of empty tables is a performance concern - I'd think the Lua interpreter itself would do some object pooling on those if it were a real problem. I wonder if there's a compilation flag the engine's missing that could provide that?
+0 / -0
|
Well, pooling only works if you create at most as much new objects as were recently disposed. Which seems to not be the case, either because more and more tables are created or because the GC actually fails to find and collect the disposable ones.
+0 / -0
|
