⚡️ Speed up function _sanitize_query_string by 1,011% in PR #11934 (temp-branch)#11935
Closed
codeflash-ai[bot] wants to merge 1 commit into
Closed
⚡️ Speed up function _sanitize_query_string by 1,011% in PR #11934 (temp-branch)#11935codeflash-ai[bot] wants to merge 1 commit into
_sanitize_query_string by 1,011% in PR #11934 (temp-branch)#11935codeflash-ai[bot] wants to merge 1 commit into
Conversation
Brief: The optimized version replaces the Python-level per-character filter ("".join(ch for ch in value if " " <= ch <= "~")) with a single, precompiled regular-expression substitution that removes characters outside the printable ASCII range. This moves the heavy work into C (the regex engine) and avoids Python bytecode overhead per character, producing the ~10x runtime improvement observed (26.0 ms → 2.34 ms).
What changed
- Replaced generator + join + per-character Python comparisons with a precompiled regex: _re_non_printable = re.compile(r"[^ -~]") and used _re_non_printable.sub("", value).
- The regex object is compiled once at module import (module-global), so repeated calls reuse the compiled pattern.
Key reasons this is faster
- Avoids per-character Python interpretation: the original generator expression executes Python bytecode and creates Python-level objects/operations for every character in the string (the line profiler shows that line dominated the runtime). The regex substitution runs in optimized C loops and reduces per-character interpreter overhead drastically.
- Single C-level pass: re.sub performs the filtering in C and is memory/cache-friendly compared to many small Python operations.
- One-time compile cost: precompiling the pattern removes the cost of parsing/compiling the regex on every call.
Behavior & correctness considerations
- Semantics are preserved: both implementations keep characters with codepoints in the inclusive range [32 (space), 126 (~)] and then call .strip() and slice. Edge cases (space-only -> becomes empty after strip, non-str inputs raise TypeError) remain the same.
- Unicode behavior matches the original character-comparison approach because both operate on Python str codepoints; non-ASCII characters outside the [32..126] range are removed.
- The precompiled regex adds a tiny import-time cost but pays off for repeated calls.
Profiling evidence
- Line profiler shows the generator/join was the dominant cost in the original implementation; after the change the regex substitution line is the main cost but its absolute time is much smaller. Overall runtime dropped from 26.0 ms to 2.34 ms (≈10x speedup).
When this matters
- Hot paths / repeated calls: huge wins when sanitizing long strings or when calling this function many times (the annotated tests include loops with 1000 calls and large inputs — these are exactly the cases that benefit most).
- Large inputs: the larger the string, the more Python per-character overhead the original code paid; regex scales much better.
Tradeoffs / risks
- Adds one import (re) and a module-level compiled pattern (negligible).
- Regex is simple and safe (no backtracking/complex patterns), so no maintainability or performance fragility introduced.
Summary
Using a precompiled regex moves the character filtering into C, eliminates Python-level looping/allocation per character, and yields the observed ~10x speedup while preserving behavior across the tested edge cases.
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (42.40%) is below the target coverage (60.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## temp-branch #11935 +/- ##
===============================================
- Coverage 35.74% 35.72% -0.02%
===============================================
Files 1532 1532
Lines 74562 74564 +2
Branches 11146 11146
===============================================
- Hits 26651 26640 -11
- Misses 46475 46488 +13
Partials 1436 1436
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Contributor
Author
|
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.
⚡️ This pull request contains optimizations for PR #11934
If you approve this dependent PR, these changes will be merged into the original PR branch
temp-branch.📄 1,011% (10.11x) speedup for
_sanitize_query_stringinsrc/backend/base/langflow/api/v1/traces.py⏱️ Runtime :
26.0 milliseconds→2.34 milliseconds(best of156runs)📝 Explanation and details
Brief: The optimized version replaces the Python-level per-character filter ("".join(ch for ch in value if " " <= ch <= "~")) with a single, precompiled regular-expression substitution that removes characters outside the printable ASCII range. This moves the heavy work into C (the regex engine) and avoids Python bytecode overhead per character, producing the ~10x runtime improvement observed (26.0 ms → 2.34 ms).
What changed
Key reasons this is faster
Behavior & correctness considerations
Profiling evidence
When this matters
Tradeoffs / risks
Summary
Using a precompiled regex moves the character filtering into C, eliminates Python-level looping/allocation per character, and yields the observed ~10x speedup while preserving behavior across the tested edge cases.
✅ Correctness verification report:
⚙️ Click to see Existing Unit Tests
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr11934-2026-02-27T09.22.43and push.