Route Packets unit setting performance impact.

[Vertu]

I have done extensive testing to figure out how my Relay unit, a flying connectable unit designed to provide connections in the air, was causing a lot of slowdown from seemingly existing.
Here is my results that made me post this. I have tried to keep everything consistent and constant.

This is how long it took for ~8 in-game seconds to run. 43 Relays existed on the map, no excessive connections.

Routes, on map.	Removed from map.	Can't route, on map.	Can route, removed then replaced onto map.
17 seconds	13 seconds	13 seconds	17 seconds

I have since employed simpler meshes and less lines of code per frame which has helped optimization a lot. But now those have been done, this is the only performance crater I can currently see as without the other craters, this became very noticeable in the absence of other sources of slowdown. So I am wondering if it may be a core issue. The removal of the Relays from the map have gave consistent performance improvement unless set to not Route packets. I have even removed all meshes and scripts with no noticeable changes on doing so.

This makes me question less how we can't have Pylon connections in CMOD units. So should I not use this unit setting on potentially performance heavy maps? I don't see a workaround.

[GoodMorning]

Is the unit moving, even slightly? If it is, any route passing through it has to be recalculated each frame, rather than cached. The same may apply if you redefine its position every frame, even if it hasn't changed.

For CW4, knu specifically changed the network to make it less laggy with so many units. I don't remember where, but if you look through his post history for "crawl" or "crawled", that should find it (if it's on Discord, that should be easily searched).

Finally, whether you have 60% slowdown or 210% slowdown, it's still an indicator that the main thread is overtaxed ... what's causing that slowdown when your Relay is not present? I know you're one of we who like to build complex scripting systems.

[Vertu]

There is no persisting change of unit position. Only within :Once and :Awake does SetUnitPosition be used and nothing is using that API onto it. It's "animation" is the moving of its sub-objects, not the unit itself so it wouldn't qualify either.
The script is very simple, just have the "animation" and change of color based on energy storage along with some convenience stuff within the :Awake and :Once calls. Like I said, I even ripped out the script and meshes to be safe.

I know it is the Relay because the absence and presence of them directly cause the noticeable change. Nothing does special calculations to them and nothing complex goes on in their script.

Also the "what's causing the slowdown when your Relay is not present" isn't really applicable when the sim speed increased by this much upon their removal from the map. In short, I have hunted down nearly all sources of slowdown but am stumped on this one.

Thanks for your input.

Edit: Unless you are implying a threshold being passed where the slight increase in performance from the removal of the Relays causes causes sim-speed to increase significantly. Sadly even this is N/A as the removal of other units in mass don't cause the change in sim-speed compared to the specific removal of Relays.

[GoodMorning]

Forgive me, I'm applying CW3/PF lag-finding tricks to a CW4 unit.

If it's taking 13s for 8s of in-game time to pass without the Relay, that seems very odd already, which is why I asked.

To narrow down the cause further, I'd suggest the traditional trick of starting from a blank slate and building a replica of the offending unit up, one step at a time, to see where the lag starts to occur.

I've seen a lot of odd tricks before, like a unit in CW3 which used the sniper-LOS check as part of energy calculations. So in any map with complex scripting, I try to have a blank map around to test the unit in isolation, to make sure that it and the game engine are the only possible explanations for whatever effect I'm seeing.


With that being said, there is another possibility. Talking to the GPU takes multiple milliseconds, and each frame only has about 32ms under ideal conditions before it starts causing lag. Half that, for anything visual. So it's possible that one of the animation-related commands you're using is causing the unit's mesh/texture/? to be pushed to the GPU. If that's happening each frame for half a dozen units, that could explain the lag. IIRC, colour-changes are probably safe, if the vertices only have attributes updated, rather than their existence being recalculated.

I hope some of that is of use to you. Good luck!

[The Apocalyptic]

Have you tried doing it WITHOUT the animation, Vertu?

I'm not really noticing any performance issues with it.

[Vertu]

Well, in the map this became a known issue to me, I had to remove most of the Relays and use elevated Pylons and Towers instead. This has dropped their amount from 43 to 20 (possibly less, I can't remember) and the performance has increased linear to how many are on the map. The map only experiences 50% of the slowdown now that about 50% of the Relays where removed.

Sadly the Relay is a very unique unit and is not complex. With the issue being the core setting of "Routes Packets" I can't do anything about it besides scrap the unit and make a new one that can not route packets and instead creates a Tower or (more likely) Pylon to serve as the means of connecting rather than the unit itself. I have done this type of parent-unit child-unit already with the Collector Panel to make floating collector panels but even then, the tower can create Soylent (can have it forced to be disarmed), Pylon has more range and packet move speed. It also doesn't help how these units are, well, towers so the visual aesthetic would be tricky.

I believe this map which I found out about this is the only map that used more than 20 or 15 Relays on it and in such quantities, the impact from the Relays is acceptable or in other words, result in a sim-speed greater than before my recent optimization revelations such as in VPAC Frontal Assault. The map is just as large (for the most part) and has around as many units but has a much faster sim-speed where as with 43 Relays the sim-speed became half of that in VPAC Frontal Assault which was unacceptable (and nearly had me scrap the map before identifying the source being from the Relay's Routes Packets setting).

I hope something happens in the future that reduces this extremity of performance taxing from just a single setting. It is even possible that in VPAC Incursion, 80% of the lag was not caused by altering the stats of core units but from the custom towers. So the confusion I had for how few units where on that map and the map size being so small compared to the slowdown experienced is probably from this same problem: Many (over 40 much like the incident with the Relays) custom units with the "Route Packets" core setting enabled.