Improve path finding and radius jewel performance - #10271
Conversation
|
A local Codex-assisted analysis found a mastery-option cache regression at A differential test restores 6 option lines on |
Good catch. That does seem to fix it. It also reminds me of how confusing the mastery options staying there when a runegraft is applied is. I'll try and make the tree show runegraft descriptions even when the node isn't allocated, as it matches the game more closely (and confuses me less) 
|
This also has the bonus of showing stat differences |
- Cache mastery options - Use multi-source bfs for closest node calculation - Look up impossible escape keystone instead of scanning every node - Avoid scanning every jewel for each node in spec
| self.build.spec.hashOverrides[selectedNode.id] = newTattooNode | ||
| self.build.spec:ReplaceNode(selectedNode, newTattooNode) | ||
| if selectedNode.type == "Mastery" then | ||
| selectedNode.allMasteryOptions = false |
There was a problem hiding this comment.
Codex follow-up found that this invalidation only runs through the interactive Add callback. Loading or restoring a saved Runegraft applies the override through ImportFromNodeList(), leaving allMasteryOptions true; the stat-difference path then skips adding the Runegraft node. Could this state be normalized whenever an AlternateMastery override is applied, so Add, reload, and redo behave identically?
db0bc67
into
PathOfBuildingCommunity:dev
3 participants
Description of the problem being solved:
This PR implements
BuildAllDependsAndPaths()and other improvements on top of the previous #10228 PR. In my totally realistic synthetic benchmark this result in around a 3x improvement in its performance. This was originally done to make radius jewel comparisons a bit faster, but they are still very slow, so the difference isn't very noticeable there. I think this is more noticeable on the passive tree where this causes less interface lag.Note that the performance was only tested with one build, which had a light of meaning, lethal pride, and an impossible escape. Still, it definitely shouldn't reduce performance for any build.
The changes include:
Steps taken to verify a working solution:
Link to a build that showcases this PR:
https://poe.ninja/poe1/pob/983a0