Hi,
Thanks for the mod :)

In relation to some micro-stutter I experienced, I got wondering why this mod was doing a huge amount of lua garbage. (causing spikes that are visible / make it dip below 60 FPS / UPS on a 9950X3D CPU with custom water cooling... )

TLDR, after realizing the amount of spawning / despawning of units ,it became clear that with over 25.000 active nests, that the way adaptive resistance is implemented might not be very CPU / runtime optimal (removing new biters, and shadow'ly keeping track of each spawners "real" biter count and then adding them if need be etc...).

Thus after a lot of research into ways to improve it(ie, trying to override the damage in on_entity_damaged etc), it seems that instead of trying to modify the biters, or the health, one could, simply, change the force's damage modifier.
Although not the "most" intuitive solution, (as it changes the tool-tips of ammo types) it would perform practically to perfect, as there are no changes to entities, and instead relies on the game engine for all damage calculations etc. This would also simplify the code, and make scaling as simple as a number, rather than entities. It would also allow multiple resistances as the same time.

I do not have a fully working example as of writing, as my hack'n slash of the code was only a short POC to verify it could work, the gist is to remove all the shadow stuff, the modifying of biters, and instead use the computed resistance(s) like the "pick_variant_for" does and instead apply them (on each change instead of spawn, so on on_entity_died I assume) like so
force.set_ammo_damage_modifier(ammo_type, -resistance / 100) -- modifier is an offset here... thus the negation

Is this something you could consider implementing?
As of now, with a large SE world, the micro-stutter (it appears to be the LUA GC) is super annoying at best, and I could only imagine on lower end hardware how bad it could be. :) I'll be happy to try and make an example if need be :) Just let me know

Thank you for this extensive report.
Could you please provide me with:
- Your mod list, including exact versions.
- The Factorio version and Smart Enemies version.
- Screenshots of show-time-usage and show-lua-object-statistics during normal play and during a stutter.
- The steps that produce the stutter, its frequency, and whether it occurs during combat, exploration, or idle play.
- The adaptive resistance setting and other Smart Enemies settings.

Also ammo_type =/= damage type and could limit mod support.

But thanks to your report i found the 2 points that need work before we start changing how the whole mod behaves
- Four native nests produced 28 units and stopped. With distant resistance variants, four nests produced 236 units and removed 208.
- Nearby resistance variants returned to native spawner ownership. The mod still included them in its separate count. It therefore counted the same units twice.

Well that was weird; i did a fast reply, and it apparently didn't show up :(
So a faster and even shorter version:
you are correct, my mistake for the simplification of ammo type vs damage type. that would never work with multiple damage types etc...
With regards to the stutter, I made a video about it:
https://tvedelab.com/factorio/smarter-ai/factorio-smarter-ai.mp4

Where the really noticeable thing is the GC timing (the max) and also the created object count (and consequently the deleted) is huge.
After trying your update and letting it update the nests (I suppose) it does seem to work way better, and not stutter at all. (also the timings are in line with normal)
Im not sure that further optimizations are needed as of now, but as far as I can tell, there are still some objects being created over and over, which may later impact performance, but until I have both proof and properly a showcase of a (next time better) solution, I would just say thank you a lot, cause I truly love your mod! Thansk! :D