-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize Creature Iteration 2: Electric Boogaloo #69574
Conversation
Can we switch our thinking about "parrot_at_danger"? No need to iterate anything and apply it only to "attack_target" .So there should be no annoying performance issues. |
I got the impression that the "attack" is meant to warn about new nearby danger other than the current target. So applying it to the attack target defeats the point. Whoever added this would have to weigh in though; I could be wrong. |
You've got it right. It has at some points in time only parroted when it could see the PC and be hostile with them. However, the intention is that dogs bark when they see zombies as an example. As long as parrot at danger causes them to speak when they see a hostile monster it is working correctly. |
ASAN failures look relevant.
|
Got a little overzealous when deleting the old faction map stuff, should be good now. |
…to optimize monster movement and parrot_at_danger.
4c61e4c
to
b0b43d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried concocting a contrived situation with clairvoyant monsters inside brick walls that hate each other, but couldn't make a situation that behaved obviously differently before than after.
Tracing a 1hr wait in a tcl blindfolded and earplugged did show about a net 16% improvement, based on exactly one before and after sample which may depend on how monster combat plays out, but it's pretty significant regardless.
When I dug into it though, the savings were a little odd. There's some savings in monster::plan, but monster::move had a larger amount of savings, through faster routing. That seems to imply that the different planning logic is resulting monsters choosing things that are cheaper to route to? Which is a divergence in behavior? Curious to hear your thoughts (or if I should just run more perf traces).
The difference is due to the fact that this optimization is also applied to parrot_at_danger, which is a move that monsters use. It is the smaller box in the PR description flame graph. |
Co-authored-by: akrieger <[email protected]>
The savings in my traces from parrot_at_danger is only ~1.4k samples, but monster::move as a whole saved ~6.3k samples. I'll take a few more traces and see if there's wider than expected variance here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took two more before & afters. monster::move bounces too much to not be noise. However monster::plan is consistently dropping at least 1/3, at best 43%. Overall about a 15% speedup including the parrot_at_danger improvement.
I'm having an issue where I've lost most of the mi-go incredibly easy and they won't respond to any noise I make such as yelling. I'll go test they still work normally in current experimental edit: Mi-go were much more successful at tracking me after losing sight of me in current experimental. Can someone else try my save and check that? |
Nope apparently once i got out of debug mode and stopped using a quickstart debug character everything started working much better. Thanks for this! |
Summary
Performance "Optimized creature iteration during monster planning and parrot_at_danger."
Purpose of change
Monster iteration in some parts of the code iterate over all monsters when they only need to iterate over monsters in their reachable zone. This causes slowdowns in high traffic areas.
Describe the solution
Moved the reachability flood fill into
creature_tracker
so it could be used in the monster planner to iterate over hostile monsters in O(monsters_in_zone) instead of O(all_monsters). Also changeparrot_at_danger
to use the same method, at it was iterating over all monsters.Describe alternatives you've considered
This was put into map in a previous PR, and the result was... not satisfactory.
Testing
Added a test, and manually checked to see if killing a monster or moving between areas would cause any errors.
Additional context
Flame before:
After:
This was previously added in PR #69176, but was causing issues and reverted in PR #69399.