Auto-evo performance

hhyyrylainen · January 19, 2026, 4:49pm

Auto-evo has recently gotten some upgrades that have made it slower. So unfortunately the amount of feedback about auto-evo taking a long time has increased. And I’ve also personally noticed that I’m waiting more for auto-evo runs if I’m testing things in freebuild.

So as I couldn’t find the other latest profiling info, here’s some fresh profiling results from master branch version. These are with JetBrains tracing profiler using a single background thread running 1 world to generation 15. Which took in total a long time (and is the reason why I ran just one world).

Interestingly in the results as much time was logged in Godot GUI stuff than auto-evo though then again I ran with 2 threads: one main and one background where auto-evo was running so that makes sense to me.

Here’s the results when scoped purely to the executor thread.

Unsurprisingly the mutation generation is the slowest thing.

Get pressure score is not very surprising that it is the most expensive method:

Having more efficient cache than Dictionary<(Species, SelectionPressure, Patch), float> would help:

For completeness here’s the rest of the pressure score parts if anyone has thoughts on improving any of them:

hhyyrylainen · January 20, 2026, 8:05am

I tested disabling the score cache and I think that that makes auto-evo performance worse, so there is at least some cache usage of the score, it just takes really long to check the cache

I ran 5 tests with the cache and 5 without. In one case the fastest run was without a cache, but at the same time 3 of the other cache-less runs were a minute slower than the slowest run with the cache

hhyyrylainen · January 20, 2026, 10:06pm

Apparently I can’t resist late night coding so I overhauled the score dictionary key and switched to an apparently faster method of reading a dictionary, and now the pressure score spends quite negligible time in dictionary lookups:

github.com/Revolutionary-Games/Thrive

Switched to a long hashed key for species and more efficient cache load

master ← auto-evo_cache_speedup

opened 10:05PM - 20 Jan 26 UTC

hhyyrylainen

+94 -45

**Brief Description of What This PR Does** This should give some noticeable a…uto-evo speed increases by purely tweaking the cache to use an apparently secret API that is just a faster dictionary lookup, and manually hashing a species score key (which should hopefully be resistant enough against any collisions). **Related Issues** auto-evo being slow: https://forum.revolutionarygamesstudio.com/t/auto-evo-performance/1226/2 **Progress Checklist** Note: before starting this checklist the PR should be marked as non-draft. - [x] PR author has checked that this PR works as intended and doesn't break existing features: https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist (this is important as to not waste the time of Thrive team members reviewing this PR) - [ ] Initial code review passed (this and further items should not be checked by the PR author) - [ ] Functionality is confirmed working by another person (see above checklist link) - [ ] Final code review is passed and code conforms to the [styleguide](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style_guide.md). Before merging all CI jobs should finish on this PR without errors, if there are automatically detected style issues they should be fixed by the PR author. Merging must follow our [styleguide](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style_guide.md#git).

hhyyrylainen · January 22, 2026, 4:19pm

As some auto-evo new changes basically undid my efficiency findings, I did a second set of cache tuning and now all caches that were useless should be removed and I increased the efficiency of the remaining ones:

github.com/Revolutionary-Games/Thrive

Second set of auto-evo data caching improvements to increase overall performance

master ← auto-evo_caching_perf_2

opened 04:14PM - 22 Jan 26 UTC

hhyyrylainen

+201 -267

**Brief Description of What This PR Does** Improved overall auto-evo performa…nce with caching performance improvements Assuming the new cache keys do not hit into cache conflicts this should not have any impact on actual results as none of the algorithms were changed, just the way the caches are handled **Related Issues** auto-evo getting slower, this should offset entirely: https://github.com/Revolutionary-Games/Thrive/pull/6563 **Progress Checklist** Note: before starting this checklist the PR should be marked as non-draft. - [x] PR author has checked that this PR works as intended and doesn't break existing features: https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist (this is important as to not waste the time of Thrive team members reviewing this PR) - [ ] Initial code review passed (this and further items should not be checked by the PR author) - [ ] Functionality is confirmed working by another person (see above checklist link) - [ ] Final code review is passed and code conforms to the [styleguide](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style_guide.md). Before merging all CI jobs should finish on this PR without errors, if there are automatically detected style issues they should be fixed by the PR author. Merging must follow our [styleguide](https://github.com/Revolutionary-Games/Thrive/blob/master/doc/style_guide.md#git).

With that I got the best auto-evo run set that I’ve seen in a while:

1:03
0:37
1:52
1:55
1:45

I’m for now done trying to squeeze more performance out so I opened some issues about TODO comments in auto-evo efficiency related things that are still not done:

github.com/Revolutionary-Games/Thrive

Properly re-use SimulationCache instances for auto-evo

opened 04:02PM - 22 Jan 26 UTC

hhyyrylainen

intermediate programming C# stage:microbe auto-evo

As they are meant to be reused so that reused caches in them can benefit from al…ready being a larger size containers. This should also hopefully help with memory management as well as there wouldn't be a bunch of temporary caches that are still allocated for the entire auto-evo run thus garbage collection is slower to remove them.

github.com/Revolutionary-Games/Thrive

Precalculate more species properties for auto-evo to be faster

opened 02:11PM - 22 Jan 26 UTC

hhyyrylainen

intermediate programming C# stage:microbe auto-evo

Profiling auto-evo I've noticed that things like total hex count, movement speed…, rotation speed, and storage capacities take quite a significant portion of any auto-evo run. I think that if those were precalculated and updated in species OnEdited that would make things faster. One slight caveat here is that auto-evo might not be calling OnEdited after each organelle change, so that's the slightly tricky part to make sure auto-evo doesn't use outdated values when testing mutations.

Finally here’s the latest measurements (though I did still have 2 caches to enable after this, but this should be relatively close to what’s going on):