Implement a caching mechanism for `RecalculatePhysicalReductionFactor` and `RecalculateMagicReductionFactor`
This cache stores the inputs (Attacker stats, level, target resistance context via enemies reference) and reuses the calculation result if inputs haven't changed
Optimize `Get_Multiplier_For_Weighted_HP_Difference` in `Champion_Total_Stats.ts` by removing `HigherDifference` array allocation and using a single `for` loop instead of `reduce` + `forEach`
This function is called frequently inside the main battle simulation loop (when certain items like Perplexity or Hellfire Hatchet are present). Array allocation and multiple array traversals were adding significant overhead
Hoist `effectiveUltimateCDCoefficient` calculation from `totalStats.Get_Effective_Ultimate_CD_Coefficient(level)` outside the `theoryIndex` loop in `Calculate_Battle` method in `src/algorithm/Battle_Calculation.ts`
Update `Adjust_Attack_Count` method signature to accept `effectiveUltimateCDCoefficient` as a new argument and use it instead of calling the method internally
Replace O(N) array search for duplicate builds with O(1) Map lookup in `Item_Scan.ts`
The original logic used `duplicatedproduct.indexOf(newUniqueId)` inside a nested loop, which scales quadratically with the number of duplicated builds
Reuse the `extraAbilityCounts` array of objects instead of creating new objects in every `init` call (which is called frequently during item set scans via `reset`)
Refactor `Adjust_Attack_Count` in `Battle_Calculation.ts` to accept `qMultiplier`, `wMultiplier`, and `eMultiplier` as individual number arguments instead of a single optional object
Updated `Calculate_Battle` to calculate these values locally and pass them directly
Optimize the `fullreset` method in `Champion_Total_Stats.ts` by hoisting loop-invariant calculations outside the scenario loop
The previous implementation recalculated stats like AD, AP, and Lethality for *every* scenario even though these values were identical across scenarios
Optimize memory allocations in the `Battle_Calculation.ts` hot loop
- Moved `ITEM_HASTE_ITEMS` array (30+ items) from `ApplyItemHasteBonus` local scope to `static readonly` property
- Hoisted `ABILITY_KEYS` array to `static readonly`
- Implemented lazy initialization for `extraAbilityKeys` inside `getMatchingAbilities` to avoid calling `Object.keys` unconditionally at the start of `Calculate_Battle` (which is often unnecessary due to caching)
Hoist loop-invariant checks (Augments, Runes) and calculations outside the scenario loop in `ChampionTotalStats.fullreset`
`fullreset` is called frequently during build calculations. The loop iterates over combat scenarios. Checks for augment/rune presence are constant across scenarios and were being repeated redundantly
Pre-calculate `totalEnemiesTargetPriority` in `Battle_Calculation.ts` and pass it to `resistance-helpers.ts` via `TheoryContext`
`getEnemiesWeighedAverageDamageReductionMultiplier` was recalculating the sum of target priorities (using `reduce`) every time it was called. This function is called multiple times inside the main battle simulation loop (`RecalculatePhysicalReductionFactor`, `RecalculateMagicReductionFactor`), leading to redundant calculations
Optimize ability haste bonus calculations
Caches augment-based haste bonuses and their cooldown multipliers to avoid redundant set lookups and repeated conversions. Refactors ability count calculations to use precomputed multipliers
Refactor overrides to use lazy per-champion storage
Migrates override settings from a single compressed redux-persist blob to a new lazy-loaded, per-champion localStorage format. Adds migration logic, updates Redux state shape, introduces async thunks for override operations, and updates UI and sagas to support the new storage model.
Update `BattleCalculation.init` to use `theory.extraAbilityKeys` (which is pre-calculated) instead of calling `Object.keys(theory.extraAbilities)` on every invocation
Reuse `BattleCalculation` instance in `Item_Scan.ts` during item comparisons
Creating a new `BattleCalculation` instance involves allocating multiple large arrays (`Damage`, `AbilityCount`, etc.)
Skip recursive component valuation when the player inventory is empty
`getOwnedComponentGold` performs recursive traversals and Set creations for every item in every potential build. In scenarios where the simulation starts with an empty inventory (which is common for "Compare Relative to No Items"), these calculations always result in 0