⚡ Bolt: Replace O(N*M) loops with O(N) hash map lookups#134
Conversation
Co-authored-by: glacy <1131951+glacy@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. |
There was a problem hiding this comment.
Pull request overview
This PR optimizes exercise/solution matching by replacing nested per-exercise linear scans with per-material hash map lookups, improving scalability for large material sets while preserving “first-match” semantics.
Changes:
- Precompute
solutions_by_labelmaps to avoid O(N*M) solution lookups inMaterialExtractor.get_all_exercisesandRAGIndexer.index_materials. - Preserve prior first-match behavior when multiple solutions share the same
exercise_labelby only inserting the first occurrence. - Apply formatting / minor import cleanup consistent with the repo’s Ruff/Black style.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
evolutia/rag/rag_indexer.py |
Uses a per-material solutions_by_label dict for O(1) solution lookup during indexing. |
evolutia/material_extractor.py |
Uses a per-material solutions_by_label dict for O(1) solution lookup when aggregating exercises. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Generar embeddings | ||
| embeddings = self._generate_embeddings_batch(chunks) | ||
|
|
||
| # Sincronizar chunks con embeddings (por si se filtraron vacíos en _generate_embeddings_batch) | ||
| # Aunque aquí preferimos filtrar antes para mantener consistencia | ||
| valid_indices = [i for i, chunk in enumerate(chunks) if chunk and chunk.strip()] | ||
| chunks = [chunks[i] for i in valid_indices] | ||
|
|
||
| if not chunks: | ||
| logger.warning( | ||
| f"Ejercicio {exercise.get('label', 'unknown')} no tiene contenido válido para indexar" | ||
| ) | ||
| return [] |
| # Generar embeddings | ||
| embeddings = self._generate_embeddings_batch(chunks) | ||
|
|
||
| # Sincronizar chunks con embeddings | ||
| valid_indices = [i for i, chunk in enumerate(chunks) if chunk and chunk.strip()] | ||
| chunks = [chunks[i] for i in valid_indices] | ||
|
|
||
| if not chunks: | ||
| logger.warning( | ||
| f"Lectura {metadata.get('title', 'unknown')} no tiene contenido válido para indexar" | ||
| ) | ||
| return [] |
💡 What: Replaced nested O(N*M) array searches with O(N) hash map lookups in
MaterialExtractor.get_all_exercisesandRAGIndexer.index_materials.🎯 Why: In large repositories, searching through a
solutionsarray linearly for every singleexercisecreates an O(N²) scaling bottleneck. Pre-computing a hash map allows for O(1) lookups, fixing the performance degradation.📊 Impact: Expected to reduce extraction and indexing times significantly for repositories with hundreds or thousands of exercises, dropping search complexity from O(N²) to O(N).
🔬 Measurement: Verified against the baseline test suite via mocked unit tests, ensuring no functionality or default "first-match" semantics were broken.
PR created automatically by Jules for task 17958961612417085706 started by @glacy