Skip to content

Performance optimizations#3

Open
Kvan7 wants to merge 9 commits into
masonk:masterfrom
Kvan7:master
Open

Performance optimizations#3
Kvan7 wants to merge 9 commits into
masonk:masterfrom
Kvan7:master

Conversation

@Kvan7
Copy link
Copy Markdown

@Kvan7 Kvan7 commented May 6, 2026

Changes from computing optimal strategy every different config of atlas to not recompute it if the nodes changed aren't effecting dropped lifeforce from a plot.
Adds memoization on the compute_optimal_value, via current plot state + current upgrades.
For my PC, went from over 10 min to compute optimal strategies to under half a second

@Kvan7
Copy link
Copy Markdown
Author

Kvan7 commented May 6, 2026

Double check the rusty portions of this, I don't really know rust so i'm not confident that is the best/normal way to do some of it

Comment thread src/bin/optimizer.rs
let mut game = GameState::from_starting_pairs(&pairs);
let optimal = game.find_optimal_strategy();
let start = &case.0;
let optimal = &case.1;
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this could be unpacked better?

@Kvan7 Kvan7 changed the title Don't recompute optimal strategy for every case Performance optimizations May 7, 2026
@Kvan7
Copy link
Copy Markdown
Author

Kvan7 commented May 7, 2026

For the optimizer changes:

Changes from computing the optimal strategy ~27k times to just 3. For me this goes from over 10 minutes to about 5 seconds to run the optimizer. Also implements caching on the optimal strategy tree navigation. Once entering the map and inside the harvest, the optimal strategy for, say BBYBYB, would be the same regardless of if i have y0_b45_p45 or y25_b45_p0. The strategy would only change if we were optimizing other atlas nodes besides those, maybe all or no atlas quant (idk why but example).

This is proven via the google sheet having same y/b/p expected outputs for every sheet

For memoization of optimal_value:

Strategy is memoizing on current plot state + current upgrades. For me this went from ~5 seconds to <0.5 seconds (ish), and appears to be computing optimal path for around the same duration as writing to files (when using optimizer) now. Logic for the memoizing strat is if i start with BB YB PP BP BP, if i pick BFromBB to start, then compute another starting position that is BP YB PP BP BP and pick BFromBP (first one... one that swapped (although maybe could do some other branch skipping looking at this example)) and the P of it wilts then my EV will be the same, since I have 1 blue upgrade. (maybe some astricks here for this hypothetical case...)

Also proven via google sheet and this producing the exact same final output. (technically there is some floating point error differences but since the sheet trims to 2 decimals it is fine, only really noticed i when I was trying to determine what to cache)

@Kvan7
Copy link
Copy Markdown
Author

Kvan7 commented May 7, 2026

Forgot if i commit to master on my fork it updates pr oops. so now this has both changes. Modified pr summary to reflect, although i can split the optimizer stuff and memoization into two commits if desired. Will make a branch on my fork if i do more stuff lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant