2020-05-27 07:12 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005723Spring engineGeneralpublic2017-09-14 08:01
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Product Version103.0 +git 
Target VersionFixed in Version 
Summary0005723: Possible performance issue in Sim::Script
DescriptionI saw 50% CPU usage in Sim::Script in this replay: http://zero-k.info/Battles/Detail/466517. What is Sim::Script?

Lua is also very high, around 70%, when it is usually much lower. The lua profilers don't say that there is any problem in luarules or luaUI.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files




Kloot (developer)

Last edited: 2017-08-22 16:24

View 2 revisions

Sim::Script is the timer for animation script updates.


hokomoko (developer)

Last edited: 2017-08-23 14:39

View 2 revisions

It is likely that something in ZK's unit scripts is munching perf. That explains both script and lua


Google_Frog (reporter)

What is the timer for animation script updates? Would the cause be something in a thread? Something in a 'script.' in a LUS?


Google_Frog (reporter)

The LUS gadget does not show high usage in widget profiler so I doubt the issue is just within lua.

Sim::Script first starts to climb at 5:41. Prior to this it fluctuates and does not exceed 0.80%. Sim::Script goes back to normal if the Rocko in this screenshot is self destructed. This unit is stuck against the factory with a fight order towards the center of the map. Its legs are in the air which would indicate that it is spamming script operations.


hokomoko (developer)

gadgethandler doesn't profile LUS correctly, so no, it doesn't indicate that.


silentwings (reporter)

The widget profiler doesn't profile the LUS gadget correctly either...


Kloot (developer)

find out how many threads are being spawned by the StartMoving callin.


Google_Frog (reporter)

Here is the script: https://github.com/ZeroK-RTS/Zero-K/blob/5be10353e84d013b9822bb4b166e0a4082496ded/scripts/cloakskirm.lua

The script seems to assume that StartMoving cannot be called twice in a row without StopMoving being called. So perhaps the unit was spamming StartMoving while stuck.


hokomoko (developer)

As a general rule of thumb, make sure that every thread function starts with Signal and SetSignalMask


Google_Frog (reporter)

Yes, obviously. But there are two questions remaining. Is it the engines responsibility to not spam StartMove and is there going to be a fix for the Rocko which is permanently stuck trying to move around a factory?


Kloot (developer)

Last edited: 2017-08-26 13:37

View 2 revisions

Fixing the second would render the first a non-issue but is not going to be as easy.

Fixing just the first could be done by insertion of a StopMoving call but might have adverse effects.


-Issue History
Date Modified Username Field Change
2017-08-22 15:34 Google_Frog New Issue
2017-08-22 15:34 Google_Frog File Added: screen00503.jpg
2017-08-22 16:20 Kloot Note Added: 0018255
2017-08-22 16:24 Kloot Note Edited: 0018255 View Revisions
2017-08-23 14:39 hokomoko Note Added: 0018260
2017-08-23 14:39 hokomoko Note Edited: 0018260 View Revisions
2017-08-23 16:45 Google_Frog Note Added: 0018261
2017-08-25 02:44 Google_Frog File Added: rockoSelfD.jpg
2017-08-25 02:44 Google_Frog Note Added: 0018269
2017-08-25 07:59 hokomoko Note Added: 0018271
2017-08-25 08:10 silentwings Note Added: 0018272
2017-08-25 13:01 Kloot Note Added: 0018274
2017-08-26 09:55 Google_Frog Note Added: 0018283
2017-08-26 10:19 hokomoko Note Added: 0018284
2017-08-26 10:24 hokomoko Assigned To => hokomoko
2017-08-26 10:24 hokomoko Status new => closed
2017-08-26 10:24 hokomoko Resolution open => no change required
2017-08-26 11:06 Google_Frog Status closed => feedback
2017-08-26 11:06 Google_Frog Resolution no change required => reopened
2017-08-26 11:06 Google_Frog Note Added: 0018285
2017-08-26 13:34 Kloot Note Added: 0018286
2017-08-26 13:37 Kloot Note Edited: 0018286 View Revisions
2017-09-14 08:01 hokomoko Assigned To hokomoko =>
+Issue History