Bug - Not A Bug Modifier Maximizer significantly slower than in the past

[ungawa]

Hey guys, has anything changed with the Modifier Maximizer in the past couple of weeks? I'm not sure exactly when it started, but I've noticed it is consistently taking several orders of magnitude longer than in the past.
I'm currently running r12912 and it just took about 3 minutes from the time I hit "update" to find maximized item drops until it returned a result and the left side turned back to green.
I'm not seeing lag when adventuring or anything else, and it's consistently just the Modifier Maximizer that is slower than I'm used to. Similar results over my work and home internet connection.

Let me know if any other info would help.

For example, here's the output from when I maximized Item Drop just now. 49 lines of "N combinations checked", each taking 3-4 seconds. I honestly don't remember if it did multiple lines of "N combinations checked" in the past or not.

Maximizing...
81321 combinations checked, best score 479.05
165317 combinations checked, best score 479.05
249138 combinations checked, best score 479.05
332346 combinations checked, best score 479.05
413578 combinations checked, best score 479.05
494546 combinations checked, best score 479.05
577822 combinations checked, best score 479.05
661540 combinations checked, best score 479.05
742754 combinations checked, best score 479.05
824511 combinations checked, best score 479.05
908011 combinations checked, best score 479.05
991318 combinations checked, best score 479.05
1074085 combinations checked, best score 479.05
1156999 combinations checked, best score 479.05
1234617 combinations checked, best score 479.05
1316645 combinations checked, best score 479.05
1400015 combinations checked, best score 479.05
1482383 combinations checked, best score 479.05
1564467 combinations checked, best score 479.05
1645505 combinations checked, best score 479.05
1728123 combinations checked, best score 479.05
1810163 combinations checked, best score 479.05
1892741 combinations checked, best score 479.05
1975395 combinations checked, best score 479.05
2056740 combinations checked, best score 479.05
2138555 combinations checked, best score 479.05
2221804 combinations checked, best score 479.05
2301858 combinations checked, best score 479.05
2384383 combinations checked, best score 479.05
2467376 combinations checked, best score 479.05
2545919 combinations checked, best score 479.05
2627951 combinations checked, best score 479.05
2702943 combinations checked, best score 479.05
2782529 combinations checked, best score 479.05
2865061 combinations checked, best score 479.05
2948309 combinations checked, best score 479.05
3031925 combinations checked, best score 479.05
3112596 combinations checked, best score 479.05
3194232 combinations checked, best score 479.05
3275420 combinations checked, best score 479.05
3356776 combinations checked, best score 479.05
3440434 combinations checked, best score 479.05
3521196 combinations checked, best score 479.05
3601105 combinations checked, best score 479.05
3683191 combinations checked, best score 479.05
3766770 combinations checked, best score 479.05
3850115 combinations checked, best score 479.05
3933408 combinations checked, best score 479.05
3977068 combinations checked, best score 479.05

Edit: And I just checked to confirm it's not just the first time when it shows the message about maximizing for the first time so it may take longer. I just maximized muscle and went back to item drop and the item drop maximization took several minutes again.

 

[roippi]

You have recently acquired more "symbiotic" gear, like hobo stuff. Working as intended.

 

[ungawa]

Heh, k, thanks. Guess that means I've been in aftercore and it's about time to go back to ascending.

 

[Darzil]

Hmm, have been wondering if it's worth a feature request to add a value of combinations not to go past. I've seen it go well above 40m combinations, but have never seen the value improve past about 100k. An early abort would mean it's not always going to be optimal in value (hence making it an option), but it'd sometimes save a lot of time.

 

[Theraze]

Could create a -symbiotic or something similar to avoid those. But I see unclear maximization strings as being a user responsibility, not something we want to force-fix.

 

[Darzil]

I'm talking about simple choices like +item drop, not an unclear string. I have all the important sets, you see, which gives KoLmafia loads of options. However, mafia is clever, so gets to the best ones fast, then searches the rest. An optional setting to abandon maximisation at a point, which I'd probably set at 1m, would save time, but cost little.

 

[xKiv]

I think one of the reasons why # of combinations explode in this case is, when you start without +item equipment worn, all shortlists have to include the "not +item" things you are currently wearing (or notwearing, if it's $item[none]). If you are already wearing a decent +item thing in a slot, it doesn't add +1 to that slot's shortlist length.
+1 doesn't look like much, but when you put it on 10 numbers that are all multiplied together, it shows very much.

I don't think that this maximizer actually uses the initial score in any way. It doesn't even seem to use any sort of bounding (it only does the "branch" part of "branch and bound").
I don't know how impossible it would be to add bounding. It definitely wouldn't be trivial, since the code would have to be repeated in all MaximizerSpeculation.try* methods, and it's not always obvious what the bounds should be (especially in presence of synergestic items ... for example, any brimstone item should probably count as +90%/6=+15% items, meat and 15 ML for this purpose). Bounds would have to be calculated from all nested slots.
The result would then be, at the top level (tryOutfits? tryFamiliarItems?) that the search would be stopped when the currently tried item is X score points worse than the first tried item, where X is "score calculated as sum of slot bounds - actual score" of best combination found so far (because any combination after that will have actual score <= its bound <= bound of best combination so far - X <= actual score of best combination so far, which proves that this "best combination so far" is actually "best combination").
Except min/max qualifiers present a huge problem for calculating bounds, because they apply with inconvenient aggregation (across all slots, but only part of the score).
Even the simples variant of that looks like it would be a lot of work, what with suddenly having to associate a new value with an AdventureResult. Lots of refactoring, at the very least.

 

[jasonharper]

If maximization is taking too long, and you think it's found a good enough combination already, you can hit ESC and have it finish up (with a warning about possible non-optimality).

 

[Theraze]

So per Jason's reply, if you think it's taking too long, you can already stop it now. Nothing says you NEED to wait to see if there's something better... so just leave it like it is and call it good?

 

[Darzil]

Yeah, it's fine if you don't do automation, and I don't.

 

[Winterbay]

I've only ever run into this while running farm which does loads of maximizations and some of them can go on forever and if you then press esc you'll have to restart which is pretty pointless. BUt as it's an automating script you don't really need to watch it do the calculations so it's not really a problem.