perf(rules): O(log N) line index + standard regex fast path + fancy_regex prefilter - #44
Merged
Merged
Conversation
…ex prefilter - byte_index_to_line_col now uses pre-built line index + binary search (was O(N) per match → O(log N), critical for large files) - execute_regex_pattern tries regex::Regex (DFA) first, falls back to fancy_regex only for backreferences/lookaround - fancy_regex with backreferences uses pre-filter via simplified standard-regex scan with 1000-match cap - Bump version to 0.4.14 4MB SQL + 10 regex rules: >30s → 425ms
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughRule execution now uses cached newline indexes for location conversion, optimized standard-regex matching, and prefiltered fallback matching for backreferences. Sequential literal matching also reuses precomputed line starts, and the crate version is bumped to 0.4.14. ChangesRule execution performance
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant RuleExecutionEngine
participant regexRegex
participant fancyRegex
participant FindingBuilder
RuleExecutionEngine->>regexRegex: compile and execute standard regex
regexRegex-->>RuleExecutionEngine: matches or compilation failure
RuleExecutionEngine->>fancyRegex: prefilter candidates and validate fallback matches
fancyRegex-->>RuleExecutionEngine: validated spans
RuleExecutionEngine->>FindingBuilder: convert offsets and construct findings
Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes 3 performance bottlenecks in rule execution:
1. O(log N) line index (was O(N²))
byte_index_to_line_colscanned from byte 0 for every match → O(M×N). Now pre-builds newline index once, binary search → O(log N) per match.4MB + 10 literal rules: >30s → 404ms
2. Standard regex fast path (was always fancy_regex)
execute_regex_patternusedfancy_regex(backtracking) for ALL patterns. Now triesregex::Regex(DFA) first, falls back tofancy_regexonly for backreferences/lookaround.3. Fancy_regex prefilter for backreferences
Backreference patterns (
\1\2) on large files (4MB) caused pathological fancy_regex backtracking. Added simplified pre-filter via standard regex + 1000-match cap.4MB + 2 backref rules: >30s → 488ms
Final benchmark
Closes #44
Summary by CodeRabbit
Performance Improvements
Bug Fixes
Release