⚡ Bolt: optimize buildCandidate array allocations - #120
Conversation
Refactor `buildCandidate` and `rsi14` to prevent `.map()`, `.slice()`, and `.reduce()` array allocations, calculating indicators via indexed for-loops directly on the underlying `bars` array. Co-authored-by: toreleon <42534763+toreleon@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
Refactor `buildCandidate` and `rsi14` to prevent `.map()`, `.slice()`, and `.reduce()` array allocations, calculating indicators via indexed for-loops directly on the underlying `bars` array. Also bumps `undici` to `>=7.29.0` to fix a high-severity vulnerability caught by `pnpm audit`. Co-authored-by: toreleon <42534763+toreleon@users.noreply.github.com>
1 participant
💡 What: Refactored
buildCandidateandrsi14insrc/tools/discover.tsto compute recent volume, prior volume, and RSI directly via bounded loops rather than chaining.map(),.slice(), and.reduce().🎯 Why:
buildCandidateis called up to ~400 times (the universe size) per search request. Previously, it mapped over up to 90 bars of data multiple times to create intermediateclosesandvolsarrays, creating significant garbage collection pressure during tight execution windows.📊 Impact: Expected reduction in memory allocations during hot loops, improving response latency consistency and dropping the overhead of ticker discovery requests under load.
🔬 Measurement: Verify correctness with unit tests (
pnpm test); verify impact by benchmarking memory allocations over several discovery runs (which execute in a similar duration but with less heap bloat).PR created automatically by Jules for task 17079003626424697993 started by @toreleon