Skip to content

⚡ Optimize game profile lookup in LocalGameDetection - #27

Open
Rukafuu wants to merge 1 commit into
mainfrom
perf-opt-game-detection-4097993275673669113
Open

⚡ Optimize game profile lookup in LocalGameDetection#27
Rukafuu wants to merge 1 commit into
mainfrom
perf-opt-game-detection-4097993275673669113

Conversation

@Rukafuu

@Rukafuu Rukafuu commented Jun 15, 2026

Copy link
Copy Markdown
Owner

💡 What: The optimization implemented

Optimized the game detection logic in LocalGameDetection by:

  1. Building an inverted index (processToGameIdMap) in the constructor to map process names to game IDs in O(1).
  2. Refactoring detectActiveGame to use a Set for running processes, allowing for O(1) membership checks.
  3. Identifying all running games first, and then iterating through the gameProfiles in their defined order of priority to select the active game.

🎯 Why: The performance problem it solves

The original code performed a nested loop over all game profiles, their associated process names, and then searched the entire list of running processes for each name using Array.prototype.some(). This resulted in O(N * M * P) complexity, which becomes inefficient as the number of supported games or running processes increases.

📊 Measured Improvement

Using a benchmark script with 106 profiles and 500 simulated processes:

  • Baseline (Original Implementation): 5.510s for 10,000 iterations.
  • Optimized Implementation: 2.597s for 10,000 iterations.
  • Improvement: ~2.1x speedup in the core detection logic.

Verification tests confirmed that game priority and specialized checks like requiresWindowCheck (football detection) remain functional and correct.


PR created automatically by Jules for task 4097993275673669113 started by @Rukafuu

This commit improves the performance of the game detection logic in the Lira Companion.
The original implementation used nested loops resulting in O(N*M*P) complexity.
The new implementation uses an inverted index (Map) for process-to-game lookups and a Set for running processes, achieving O(P + G) complexity while maintaining the original profile priority.

Performance Impact:
- Baseline (Original): ~5.5s for 10,000 iterations (106 profiles, 500 processes)
- Optimized: ~2.6s for 10,000 iterations (including process list parsing)
- Net improvement: ~2.1x faster at scale.

Co-authored-by: Rukafuu <111822334+Rukafuu@users.noreply.github.com>
@google-labs-jules

Copy link
Copy Markdown
Contributor

👋 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 @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@vercel

vercel Bot commented Jun 15, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
lira-os Ready Ready Preview, Comment Jun 15, 2026 5:37pm

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