⚡ Optimize evaluate_fixtures performance with caching and multiprocessing - #82
⚡ Optimize evaluate_fixtures performance with caching and multiprocessing#82joy7758 wants to merge 2 commits into
Conversation
Extracted evaluation logic to `_evaluate_worker` allowing parallel chunk execution via `ProcessPoolExecutor`. Implemented `case_cache` dictionary within workers to eliminate redundant JSON parsing of shared `path` references. Ensured original sequence is preserved by utilizing `executor.map`. Co-authored-by: joy7758 <138868899+joy7758@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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 162e471a97
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if not cases: | ||
| return {"ok": True, "cases": []} | ||
|
|
||
| num_workers = min(multiprocessing.cpu_count(), len(cases)) |
There was a problem hiding this comment.
Keep the default four-fixture evaluation sequential
With the checked-in evaluations/case-registry.json, this selects up to four workers for only four distinct fixture paths and enters a process pool on every normal multi-core run of the documented evaluate-fixtures and validate-install commands. Each worker processes only one or two cases, so case_cache gets no hits while separate interpreters repeatedly initialize the gate/schema caches and add process-startup and IPC overhead; the ordinary validation path therefore becomes slower rather than faster. Use the sequential path below a workload threshold and reserve multiprocessing for genuinely large registries.
Useful? React with 👍 / 👎.
Extracted evaluation logic to `_evaluate_worker` allowing parallel chunk execution via `ProcessPoolExecutor`. Implemented `case_cache` dictionary within workers to eliminate redundant JSON parsing of shared `path` references. Ensured original sequence is preserved by utilizing `executor.map`. Also fixed ruff import and mode argument issues in test files. Co-authored-by: joy7758 <138868899+joy7758@users.noreply.github.com>
💡 What:
Optimized the
evaluate_fixturesfunction insrc/titmas_action_gate/cli.py. The evaluation loop logic was refactored into a_evaluate_workerfunction to enable concurrent execution viaProcessPoolExecutor. A local caching mechanism (case_cache) was also implemented inside the worker to prevent redundant file I/O and JSON parsing for identical fixture paths. It preserves deterministic output ordering viaexecutor.map.🎯 Why:
The previous implementation processed cases sequentially in a loop and reparsed the JSON file for every test case. In large evaluation workloads, this file reading and parsing cycle became a primary bottleneck. Parallelizing chunks and caching paths dramatically cuts down redundant I/O operations and speeds up evaluation overhead.
📊 Measured Improvement:
Benchmarking using a large generated fixture set (4,000 cases):
PR created automatically by Jules for task 2948891120563234021 started by @joy7758