Skip to content

Increase URL parsing speed by approximately 2 times - #1139

Open
AyumuKasuga wants to merge 2 commits into
pydantic:mainfrom
AyumuKasuga:perf-urlparse-hot-path
Open

Increase URL parsing speed by approximately 2 times#1139
AyumuKasuga wants to merge 2 commits into
pydantic:mainfrom
AyumuKasuga:perf-urlparse-hot-path

Conversation

@AyumuKasuga

@AyumuKasuga AyumuKasuga commented Aug 15, 2026

Copy link
Copy Markdown

urlparse rejects the ASCII control characters that are not permitted. To find these characters, it examined each character of the URL, and each character of each keyword component. It used a generator in Python. A profile of httpx2.URL(...) shows that this generator uses approximately 43 percent of the parse time.

The ASCII characters that are not printable are exactly the C0 control characters and DEL. One compiled regex search can replace the generator. The match object gives the character and also its position. The second pass to find the character is not necessary. The error messages and the character positions do not change.

This commit also makes two smaller changes to quote. urlparse calls this function five times for each URL.

  • Call PERCENT_ENCODED_REGEX.finditer(...) and not re.finditer(PERCENT_ENCODED_REGEX, ...). The second form repeats the re._compile cache operation at each call.
  • Call percent_encoded immediately if the string contains no '%' character. Most strings do not contain this character.

The measurements use 40 rounds. Each variant runs in its own process. The order of the two variants changes at each round. A change in the condition of the machine thus has an equal effect on both variants. The values are medians:

short           (25 characters)     4.61us ->   2.57us   1.79x
typical         (69 characters)     7.42us ->   3.64us   2.04x
percent-encoded (70 characters)     7.85us ->   4.91us   1.60x
long query      (1 KB)             30.31us ->  12.28us   2.47x

For a full client request cycle with MockTransport, the time decreases from 25.31us to 20.54us for a typical URL. For a URL that has a long query string, the time decreases from 48.90us to 29.13us. The two sets of samples do not overlap. In each case, the slowest of the 40 new samples is faster than the fastest of the 40 old samples.

A test compares the new character class with the previous condition for all 1114112 Unicode code points. The two sets of characters are equal. A second test compares the new implementation with the previous one for approximately 60000 fixed and random URLs and keyword component calls. The results and the exception messages are the same.

The new tests use the limits of the control character ranges, CR, the printable characters that are adjacent to the limits, and characters that are not printable and are not ASCII. The new benchmarks use a long URL and a URL that contains '%xx' escape sequences.

Summary

Checklist

  • I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.

Review in cubic

`urlparse` rejects the ASCII control characters that are not permitted.
To find these characters, it examined each character of the URL, and
each character of each keyword component. It used a generator in
Python. A profile of `httpx2.URL(...)` shows that this generator uses
approximately 43 percent of the parse time.

The ASCII characters that are not printable are exactly the C0 control
characters and DEL. One compiled regex search can replace the
generator. The match object gives the character and also its position.
The second pass to find the character is not necessary. The error
messages and the character positions do not change.

This commit also makes two smaller changes to `quote`. `urlparse` calls
this function five times for each URL.

* Call `PERCENT_ENCODED_REGEX.finditer(...)` and not
  `re.finditer(PERCENT_ENCODED_REGEX, ...)`. The second form repeats
  the `re._compile` cache operation at each call.
* Call `percent_encoded` immediately if the string contains no '%'
  character. Most strings do not contain this character.

The measurements use 40 rounds. Each variant runs in its own process.
The order of the two variants changes at each round. A change in the
condition of the machine thus has an equal effect on both variants.
The values are medians:

    short           (25 characters)     4.61us ->   2.57us   1.79x
    typical         (69 characters)     7.42us ->   3.64us   2.04x
    percent-encoded (70 characters)     7.85us ->   4.91us   1.60x
    long query      (1 KB)             30.31us ->  12.28us   2.47x

For a full client request cycle with `MockTransport`, the time
decreases from 25.31us to 20.54us for a typical URL. For a URL that has
a long query string, the time decreases from 48.90us to 29.13us. The
two sets of samples do not overlap. In each case, the slowest of the 40
new samples is faster than the fastest of the 40 old samples.

A test compares the new character class with the previous condition for
all 1114112 Unicode code points. The two sets of characters are equal.
A second test compares the new implementation with the previous one for
approximately 60000 fixed and random URLs and keyword component calls.
The results and the exception messages are the same.

The new tests use the limits of the control character ranges, CR, the
printable characters that are adjacent to the limits, and characters
that are not printable and are not ASCII. The new benchmarks use a long
URL and a URL that contains '%xx' escape sequences.
@codspeed-hq

codspeed-hq Bot commented Aug 15, 2026

Copy link
Copy Markdown

Merging this PR will improve performance by 31.78%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 4 improved benchmarks
✅ 13 untouched benchmarks
🆕 2 new benchmarks
⏩ 7 skipped benchmarks1

Performance Changes

Mode Benchmark BASE HEAD Efficiency
Simulation test_bench_url_parse 144.6 µs 85.7 µs +68.65%
Simulation test_bench_url_join 229.3 µs 158.4 µs +44.74%
Simulation test_bench_request_multipart 285.4 µs 256.6 µs +11.2%
Simulation test_bench_request_json_post 500 µs 450 µs +11.11%
🆕 Simulation test_bench_url_parse_long_query N/A 119.1 µs N/A
🆕 Simulation test_bench_url_parse_percent_encoded N/A 93.9 µs N/A

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.


Comparing AyumuKasuga:perf-urlparse-hot-path (085f98f) with main (829b93a)

Open in CodSpeed

Footnotes

  1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 4 files

Re-trigger cubic

Each other entry in the changelog gives a link to its pull request.
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