I do not know if it is possible to delve this far into the code, but would it be possible to just make 50 builder drones, then just have them allocated to whatever is on screen, then if anything beyond that needs them to just ignore them. So an object pool of only 50 or something.
Also, what files and such is the code for this all contained in? I have some free time coming up and could look at it.
You must deceive the enemy, sometimes your allies, but you must always deceive yourself!
The problem with caching units is that they still take part in the sim calculations - slowing it down. The allocation / de-allocation of the units only cause a stutter - their existence cause a slow down.
I am working on it as I am writing this and currently managed to get 150 t3 engineers down to 'just' 6 - 7 ms increase when building. I'm aiming for this to be a lot lower than that. I'm in the Discord channel (soon - after finishing dinner) if you're interested in seeing the approach.
A work of art is never finished, merely abandoned
@jip Sure. Ill take a look. I have the same name there.
You must deceive the enemy, sometimes your allies, but you must always deceive yourself!
After sitting down with Marlo, Kale, Kazbek and a few others we managed to get the hit of the sim speed at around 6 ms for 150 t3 engineers when building, instead of 10 - 11. If we go with the idea that higher tech engineers have bigger drones (and therefore less drones) we can even get faster than UEF / Seraphim drones, cutting it down to about 3 ms when they start building.
You can see in the previous post how it looks like with 150 engineers and each engineer having 3 drones.
This is how it looks like for 150 engineers, when they have 'bigger' drones:
What we did is:
In the long run the number of table allocations per drone is reduced drastically, the drones execute far less logic overall and the number of effects are reduced without impacting the overall aesthetics too much (in my / our opinion).
Tomorrow I'm going to try and finish it up.
An important disclaimer: the 6 vs 10/11 ms is the situation where the t3 engineer spawns the same number of drones as it did before. Meaning - we made them faster, and almost by a factor of 2. Let alone that the garbage collector is better off too causing less stutters.
A work of art is never finished, merely abandoned
Aw man, do the logic reworks mean I can no longer block MMLs with drones? (Jk all these changes sound awesome)
150 hives:
Left side: 1 ms when off, 5.0 - 5.5 ms when turned on
Right side: 1ms when off, 22 - 23 ms when turned on
Note:
150 t3 engineers:
Left side: 1.2ms when off, 5.5 ms when turned on
Right side: 1.2 ms when off, 14 - 15ms when turned on
Note:
And when you have less engineers (3x t3). The beams of the engineer go to the same point, all drones go to the same point.
When you have t1 engineers - these look exactly the same as there is only one build arm and only one bot, each having their own unique build spot.
150 t1 engineers:
Left side: 1.2 ms when off, 4 ms when turned on
Right side: 1.2 ms when off, 5.5 - 6 ms when turned on
150 hives:
Left side: 1 ms when off, 4 - 4.5 ms when on
Right side: 1 ms when off, 15.5 - 15.5 ms when on.
Note:
Disclaimer:
With some additional work from MadMax on the models this entire PR should be ready for review later this week 
A work of art is never finished, merely abandoned
And a more visual comparison: https://youtu.be/YZDU5mf1eOs
Copy of the description:
We have two instances of the game open - each having their own cores assigned. Made sure to assign the recorder on different cores ( 01:50)
10x t1 engineers: 01:00
40x t2 engineers: 02:00
50x t3 hives: 04:00
150x t1 engineers: 11:00
All numbers are in milliseconds.
1.8 - 2 vs 3.3 - 3.5 (40x tech 2 engineers, 02:45)
2 - 2.3 vs 7.0 - 8 (50x tech 3 hives, 04:25)
1.9 - 2.2 vs 5.0 (50x tech 3 hives, 05:45)
4.5 - 5.0 vs 5.0 - 5.5 (150x tech 1 engineers, zoomed in, 11:40)
2.8 - 3.0 vs 4.4 - 4.5 (150x tech 1 engineers, zoomed out, 12:20)
Performed on a Ryzen 5 3600 6-core processor with 64gb of dual-ram. Numbers may vary on different machines, but their relative impact should not.
Zooming out matters because it shows how much the emitters impact the sim in comparison to the bots of the units. Zooming out represents the performance hit on your opponents - they likely never get to see the emitters of buildings being built. They only see the emitters of engineers being blown up.
@arma473 I hope this provides the side-by-side comparison you were looking for.
edit: it is still processing the HD version
A work of art is never finished, merely abandoned
@captainklutz Not yet. We double checked and they do definitely have a collider, and thus tax performance by adding to that. We tried a few approaches to remove that but to no avail. Technically, removing their collider would be a gameplay change, and not strictly a cosmetic one (as Jip is attempting here). Though I am not actually sure if they block projectiles or missiles, have you had this happen?
You must deceive the enemy, sometimes your allies, but you must always deceive yourself!
@captainklutz said in Questions about performance: Cybran build drones:
Aw man, do the logic reworks mean I can no longer block MMLs with drones? (Jk all these changes sound awesome)
Didn't see this message.
Yes - that is what it means hahaha. As Kale mentioned, we tried to get rid of the collision box all together. But that made the game unstable and caused it to crash to Desktop (fast game though).
A work of art is never finished, merely abandoned
Loud removed them completely didn't they? and they got tons of performance from it. worth it. IMO. the graphics are less important than performance.
That isn't true and we all know it. Graphics is as much part of a game as the gameplay is, especially for people that are just starting out. This PR will bring the costs of cybran engineers in the same range as any of the other engineers, without impacting the aesthetics too much. Imagine the speedup when you're playing with four cybrans in the game, all making hives at some point .
A work of art is never finished, merely abandoned
@tatsu I 100% get you. you are right, but only to a degree. Most of us play "icon manager" from the far zooms, so it's the norm, but in the interests of growing the community keeping some of the interesting aesthetics is important. After all we command around robots and tanks, not datatype UEL0106@0xffaff99
You must deceive the enemy, sometimes your allies, but you must always deceive yourself!
Awesome improvements!
I have one small nitpick, though: It looks a bit awkward when the SACU or a hive has multiple drones and they all weld the same spot. In my personal opinion I would give them back the needed number of dummy entities. I would focus on other non-visual performance improvements first. You mentioned that there is actually a lot to gain by just optimizing a lot of function logic all over the game. If we after that see that we absolutely want to squeeze the last performance drops out of the game, we can still talk about optimizing the drones even more.
@BlackYps I can experiment with removing that part of the optimization, but it will introduce some additional emitters too (for the welding effect). Note that for tech 1 engineers the aesthetics are the same.
A work of art is never finished, merely abandoned
@BlackYps After thinking about it a bit more I am reluctant. The reason I choose for having a constant number of weld points (one for the builder, one for all drones) is to prevent using tables. Tables need to be allocated and (eventually) deallocated. Deallocation is something we have no control over, that is what the garbage collector does for us and that is part of the stuttering that you see late game when you would be able to speed up the game. That is why Crotalus is looking into whether we can reduce the table count in various places.
The problem with it is that I can not definitively tell you that not having tables will reduce stuttering. We have no control or info over the garbage collector as to what it clears, when it clears it and whether it causes stutters. All we know is that it runs quite aggressively and quite often (each one or two seconds) and that is also the stuttering that you can see in the video. Because of it we can not test how much these (relative small, but in large amounts) table allocations 'cost' us indirectly, I can only give you a gut feeling that it matters.
I am making it look more natural, specifically:
All these changes have no impact on the sim, but it does look better.
A work of art is never finished, merely abandoned
Doesn't the same apply for all things in memory? If you have a single dumy entity per hive you still need to allocate and deallocate it.
You are more experienced than me, so if you feel that it is a big issue, then I can't really argue against it.
I just wanted to remind that we don't have to try to fix every performance issue by focusing on the cybran drones and there are other topics to tackle that won't have any visual implications at all.
Although I realize that it is a bit shitty to come around the corner and say "You know, maybe you should not implement this and work on something else first" after the work has already been done, but I didn't really have time for this earlier.
Doesn't the same apply for all things in memory? If you have a single dumy entity per hive you still need to allocate and deallocate it.
Yes - the (constant - two) entities would still need to be allocated / deallocated. But we can hold a constant number of references on the stack, where as the latter would require a table to keep the references each time a cybran engineer decides to build something and spawns drones. That table is part of the heap, where we keep a reference to the table on the stack. Common example when table re-allocation is quite high: when assisting a factory the drones tend to go away before the next unit is made. This means that for each unit we make / assist we allocate tables that we just threw out.
I just wanted to remind that we don't have to try to fix every performance issue by focusing on the cybran drones and there are other topics to tackle that won't have any visual implications at all.
I understand, but I also think that if we can do without then why should we go with. Note that:
edit: and to answer to this:
Although I realize that it is a bit shitty to come around the corner and say "You know, maybe you should not implement this and work on something else first" after the work has already been done, but I didn't really have time for this earlier.
This is by far the biggest change we can make to the game in three to four days of work. Imagine having to play an eco map where everyone builds hives and just losing 30 ms instead of 5 ms (where you have 100ms a tick!) of the sim to hives for the sake of hives being hives.
A work of art is never finished, merely abandoned
