perf(utils/url): Short circuit the regex in checkOptionalParameter

[csainty]

Here's a small suggestion to short-circuit the checkOptionalParameter check without doing a regex match when we can O(1) determine it won't match.

It's a small optimization, but for the LinearRouter in an environment with a lot of routes it is a non-trivial improvement.

Before

• GET /user
LinearRouter   1'382 ns/iter     (1'208 ns … 277 µs)  1'334 ns  1'667 ns  5'333 ns

• GET /user/comments
LinearRouter   1'422 ns/iter   (1'377 ns … 1'531 ns)  1'436 ns  1'498 ns  1'531 ns

• GET /user/lookup/username/hey
LinearRouter   4'321 ns/iter   (4'205 ns … 4'551 ns)  4'381 ns  4'551 ns  4'551 ns

• GET /event/abcd1234/comments
LinearRouter   1'610 ns/iter   (1'545 ns … 1'787 ns)  1'626 ns  1'769 ns  1'787 ns

• POST /event/abcd1234/comment
LinearRouter     737 ns/iter     (692 ns … 3'858 ns)    745 ns    926 ns  3'858 ns

• GET /very/deeply/nested/route/hello/there
LinearRouter   1'586 ns/iter   (1'516 ns … 4'462 ns)  1'579 ns  2'244 ns  4'462 ns

• GET /static/index.html
LinearRouter   1'398 ns/iter   (1'345 ns … 1'512 ns)  1'412 ns  1'500 ns  1'512 ns

After:

• GET /user
LinearRouter   1'062 ns/iter       (875 ns … 307 µs)  1'041 ns  1'416 ns  4'750 ns

• GET /user/comments
LinearRouter   1'108 ns/iter   (1'067 ns … 1'232 ns)  1'126 ns  1'206 ns  1'232 ns

• GET /user/lookup/username/hey
LinearRouter   3'897 ns/iter   (3'814 ns … 4'120 ns)  3'904 ns  4'120 ns  4'120 ns

• GET /event/abcd1234/comments
LinearRouter   1'281 ns/iter   (1'214 ns … 1'517 ns)  1'293 ns  1'413 ns  1'517 ns

• POST /event/abcd1234/comment
LinearRouter     410 ns/iter       (373 ns … 528 ns)    446 ns    473 ns    528 ns

• GET /very/deeply/nested/route/hello/there
LinearRouter   1'288 ns/iter   (1'207 ns … 1'402 ns)  1'315 ns  1'383 ns  1'402 ns

• GET /static/index.html
LinearRouter   1'112 ns/iter   (1'031 ns … 1'200 ns)  1'139 ns  1'182 ns  1'200 ns

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[jimutt]

+1 I agree it's worth within the context/environment of which Hono is often applied, it's one of the optimizations that one would prefer to avoid maintaining a full fork for.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.29%. Comparing base (8796371) to head (85d1c78).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3974      +/-   ##
==========================================
- Coverage   91.29%   91.29%   -0.01%     
==========================================
  Files         168      168              
  Lines       10772    10771       -1     
  Branches     3057     3140      +83     
==========================================
- Hits         9834     9833       -1     
  Misses        937      937              
  Partials        1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yusukebe]

Hi @csainty

Awesome! But I would like to confirm. Is the benchmark script that you used benchmarks/routers/src/bench-includes-init.mts, not bench.mts?

[csainty]

Yes that it correct

[yusukebe]

LGTM!

[yusukebe]

Hey @usualoma Can you review this?

[usualoma]

Hi, @csainty. Thank you. Good improvement!

I want to use !== as the comparison operator, and if I'm going to use this pattern, I want to replace subsequent condition to be .includes(':')

[usualoma]

@csainty Thank you. LGTM!

[yusukebe]

@usualoma Thank you for reviewing.

@csainty Awesome work! I appreciate your contribution. Merging.