You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came across this PR from Deno's fresh framework that might be beneficial to Rutt.
The PR is a fix to speed up the slow matching of static routes where previously, each static file route had its own URLPattern instance. This approach was slow and did not allow for an exact match.
What the PR proposes is to extend the route pattern to either be URLPattern or string. If the route pattern is a string, they treat it as an exact match, the URL is parsed, and a regex match is avoided. This is only applicable for internally created patterns; user-supplied patterns will still be parsed into URLPattern like before.
The author has reported significant improvements with this fix, reducing route-matching time from 62ms down to 0.7ms in real-world testing.
I think it could be an interesting enhancement for the routing in Rutt as well. It may be worth considering whether similar improvements can be implemented.
The text was updated successfully, but these errors were encountered:
nestarz
changed the title
Consider Incorporating PR to Speed Up Matching Static Routes
Speed up the slow matching of static routes
Nov 14, 2023
I came across this PR from Deno's fresh framework that might be beneficial to Rutt.
The PR is a fix to speed up the slow matching of static routes where previously, each static file route had its own URLPattern instance. This approach was slow and did not allow for an exact match.
What the PR proposes is to extend the route pattern to either be URLPattern or string. If the route pattern is a string, they treat it as an exact match, the URL is parsed, and a regex match is avoided. This is only applicable for internally created patterns; user-supplied patterns will still be parsed into URLPattern like before.
The author has reported significant improvements with this fix, reducing route-matching time from 62ms down to 0.7ms in real-world testing.
I think it could be an interesting enhancement for the routing in Rutt as well. It may be worth considering whether similar improvements can be implemented.
The text was updated successfully, but these errors were encountered: