* Use value rules for timer
* lint
* fix rule overrides
* fix the "boolean" value rules
* add limits for number based rules
* Realized that you don't need boolean value rules
* oops
* fix checks for lower bounds
* add crude profiling to runDexSearch
No behavioral changes (other than console.log spam), this commit is just to establish a baseline and pinpoint the slow portions
* optimize datasearch.ts - pull move filter prep out of loop
Based on preliminary benchmarks, most of the time was spent getting the move validator, even for queries that don't specify a move.
More importantly, the parameters for fetching the move validator are known very early in the function and don't change during the loop.
Pulling that portion out of the loop is an easy win.
* improve profiling for runDexSearch
- add subcategories for filtering on move (the next optimization target)
- report unaccounted time amounts ('known unknowns')
- make grand total stand out more
* optimize dexsearch - fetch move list in outer loop
Move list depends on 'alts', which does not change in the loop over mons. Minor win, but simple.
* optimize dexsearch - filter move list by gen in outer loop
Neither 'mod' nor 'altMoves' changes during the inner loop.
* log pokemonSource in runDexSearch - expose possible leak
pokemonSources, which appears to act as a set, grows with each iteration, adding seemingly redundant items.
Will need to look closely at TeamValidator to identify the problem. My guess is that it's putting object references into a Set,
which, for objects other than strings, only cares about object identity.
* profile runDexSearch - count checkCanLearn calls
Also, semi-fix issue identified in prior commit - the endless growth of the restrictiveMoves list.
Counting the calls to checkCanLearn helps us reason about whether the cost per call is reasonable.
* fix perf bug in TeamValidator.checkCanLearn
use the cached ruleTable, save 100x.
* optimize runDexSearch - only init move filters when needed
For queries that never mention a move, a considerable chunk of time is wasted getting the objects needed for
'checkCanLearn'. I measure ~1ms savings for the relevant queries, which is often a decent percentage.
* profile dexsearch - delete and format
This is to document that they are not the bottlenecks.
* remove nested profiling from dexsearch
We've gotten to the point where we actually *are* measuring microseconds, so the frequent calls
are too expensive. This is a good problem to have! What we can see from running npm test is
that 'filters' and 'unaccounted' still account for a majority of the time. So, there's still
room for improvement, if that's ever a serious concern.
Personally, I think working on the moves API would be more fruitful.
* remove all profiling code
No more console.log or performance.now() calls. Ready to merge.
* Update server/chat-plugins/datasearch.ts
Format the 'format' string in-line.
Co-authored-by: Mia <49593536+mia-pi-git@users.noreply.github.com>
* Remove ts-expect-error from datasearch.ts
* Fix uninit lint in runDexSearch
---------
Co-authored-by: Mia <49593536+mia-pi-git@users.noreply.github.com>
