♻️ Refactor: optimize routeParser by using sync.Pool

[ksw2000]

Description

This PR optimizes the routeParser by leveraging sync.Pool to efficiently manage short-lived objects. The benchmark results show a significant reduction in execution time by 13.84%, memory allocation by 14.52%, and allocation count by 29.99%.

goos: linux
goarch: amd64
pkg: github.com/gofiber/fiber/v3
cpu: AMD EPYC 9J14 96-Core Processor
                                                                               │   ori.txt   │              pool.txt               │
                                                                               │   sec/op    │   sec/op     vs base                │
_RoutePatternMatch//api/v1/const_|_match_|_/api/v1/const-16                      173.9n ± 0%   159.3n ± 1%   -8.37% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1-16                        163.9n ± 0%   150.9n ± 0%   -7.90% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/-16                       165.4n ± 1%   150.6n ± 1%   -8.95% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/something-16              174.9n ± 0%   160.6n ± 0%   -8.15% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_match_|_/api/abc/fixedEnd-16           520.2n ± 0%   438.1n ± 1%  -15.78% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_not_match_|_/api/abc/def/fixedEnd-16   521.8n ± 0%   436.8n ± 0%  -16.29% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity-16                  630.0n ± 0%   525.0n ± 0%  -16.67% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/-16                 633.3n ± 0%   526.4n ± 0%  -16.89% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/1-16                627.8n ± 0%   527.5n ± 0%  -15.97% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v-16                      602.1n ± 0%   501.9n ± 0%  -16.65% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v2-16                     604.9n ± 0%   504.3n ± 0%  -16.62% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v1/-16                    616.7n ± 0%   512.8n ± 1%  -16.86% (p=0.000 n=20)
geomean                                                                          390.5n        336.5n       -13.84%

                                                                               │  ori.txt   │              pool.txt              │
                                                                               │    B/op    │    B/op     vs base                │
_RoutePatternMatch//api/v1/const_|_match_|_/api/v1/const-16                      152.0 ± 0%   144.0 ± 0%   -5.26% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1-16                        144.0 ± 0%   136.0 ± 0%   -5.56% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/-16                       144.0 ± 0%   136.0 ± 0%   -5.56% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/something-16              160.0 ± 0%   152.0 ± 0%   -5.00% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_match_|_/api/abc/fixedEnd-16           440.0 ± 0%   368.0 ± 0%  -16.36% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_not_match_|_/api/abc/def/fixedEnd-16   440.0 ± 0%   368.0 ± 0%  -16.36% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity-16                  536.0 ± 0%   432.0 ± 0%  -19.40% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/-16                 536.0 ± 0%   432.0 ± 0%  -19.40% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/1-16                536.0 ± 0%   432.0 ± 0%  -19.40% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v-16                      528.0 ± 0%   424.0 ± 0%  -19.70% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v2-16                     528.0 ± 0%   424.0 ± 0%  -19.70% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v1/-16                    528.0 ± 0%   424.0 ± 0%  -19.70% (p=0.000 n=20)
geomean                                                                          337.9        288.8       -14.52%

                                                                               │   ori.txt   │              pool.txt              │
                                                                               │  allocs/op  │ allocs/op   vs base                │
_RoutePatternMatch//api/v1/const_|_match_|_/api/v1/const-16                       5.000 ± 0%   4.000 ± 0%  -20.00% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1-16                         5.000 ± 0%   4.000 ± 0%  -20.00% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/-16                        5.000 ± 0%   4.000 ± 0%  -20.00% (p=0.000 n=20)
_RoutePatternMatch//api/v1/const_|_not_match_|_/api/v1/something-16               5.000 ± 0%   4.000 ± 0%  -20.00% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_match_|_/api/abc/fixedEnd-16           13.000 ± 0%   9.000 ± 0%  -30.77% (p=0.000 n=20)
_RoutePatternMatch//api/:param/fixedEnd_|_not_match_|_/api/abc/def/fixedEnd-16   13.000 ± 0%   9.000 ± 0%  -30.77% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity-16                  14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/-16                 14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_match_|_/api/v1/entity/1-16                14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v-16                      14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v2-16                     14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
_RoutePatternMatch//api/v1/:param/*_|_not_match_|_/api/v1/-16                    14.000 ± 0%   9.000 ± 0%  -35.71% (p=0.000 n=20)
geomean                                                                           9.811        6.868       -29.99%

Type of change

• Performance improvement (non-breaking change which improves efficiency)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

• Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
• Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.
• Provided benchmarks for the new code to analyze and improve upon.

Commit formatting

Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md

[coderabbitai]

Walkthrough

The changes introduce a synchronization mechanism for the routeParser struct in path.go by using a sync.Pool. A new variable, routerParserPool, is added to manage reusable routeParser instances. The RoutePatternMatch function now retrieves a parser from the pool, resets its state using a new reset method, and returns it after use. Additionally, methods such as parseRoute, analyseParameterPart, and getMatch have been refactored to operate as receivers on routeParser, ensuring the instance’s fields are properly utilized and reset between parses.

Changes

File(s)	Change Summary
path.go	Added routerParserPool using sync.Pool; introduced the reset method for routeParser; refactored parseRoute, analyseParameterPart, and getMatch to be methods on routeParser to enable instance reuse with proper state clearance.

Sequence Diagram(s)

Loading

sequenceDiagram
    participant Caller as Caller
    participant Pool as routerParserPool
    participant Parser as routeParser
    Caller->>Pool: Request parser instance
    Pool-->>Caller: Return parser (new or reused)
    Caller->>Parser: Call reset() to clear state
    Caller->>Parser: Execute parseRoute, analyseParameterPart, getMatch
    Caller->>Pool: Return parser to pool

Poem

I’m a little rabbit, hopping through code so free,
Sync.Pool in sight, making routes as crisp as can be.
I reset each parser with a hop and a skip,
Ensuring fresh starts with each method’s trip.
CodeRabbit cheers—let's bounce to a cleaner spree!

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Free

📥 Commits

Reviewing files that changed from the base of the PR and between 600ebd9 and ef23d82.

📒 Files selected for processing (1)

• path.go (8 hunks)

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.58%. Comparing base (600ebd9) to head (ef23d82).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3343      +/-   ##
==========================================
- Coverage   83.66%   83.58%   -0.08%     
==========================================
  Files         118      118              
  Lines       11711    11723      +12     
==========================================
+ Hits         9798     9799       +1     
- Misses       1485     1493       +8     
- Partials      428      431       +3     

Flag	Coverage Δ
unittests	83.58% <100.00%> (-0.08%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ReneWerner87]

Thanks, there should still be a lot possible when parsing the route
At that time we had only optimized the detection, i.e. the matching, since the parsing takes place before the start of the application and was not performance critical

[JIeJaitt]

@ksw2000 Hello, how did you find out so many performance optimizations for fiber? Is there any tool? I also want to use it in my project.

[ksw2000]

@ksw2000 Hello, how did you find out so many performance optimizations for fiber? Is there any tool? I also want to use it in my project.

@JIeJaitt I didn't use any special tools, just benchstat to compare benchmark test results.

[ksw2000]

Thanks, there should still be a lot possible when parsing the route At that time we had only optimized the detection, i.e. the matching, since the parsing takes place before the start of the application and was not performance critical

@ReneWerner87 I'll try analyzing the bottlenecks in the server's operation (application start time). There are still many parts of the project I'm not very familiar with, so for now, I'm just submitting improvements whenever I spot them.

[gaby]

@ksw2000 Did you check if using fasthttp/bytesbufferpool make any difference?

We already have it as a dependency on the project.

[ksw2000]

@ksw2000 Did you check if using fasthttp/bytesbufferpool make any difference?

We already have it as a dependency on the project.

@gaby
In this PR, sync.Pool is used to optimize the routeParser struct, not for byte slices.

[gaby]

👍 LGTM