Route priority
See original GitHub issueFirst of all, really cool project, congrats!
I took a look at the internals and I see that you loop over the array of routes when you try to find one and push to it every time a new route is added. I thought that we could pass some kind of priority when adding a route so instead of just pushing it to the end of the list we have some sort of ranking algorithm that add the route in the right index. Maybe the priority could be a number between 1 to a 100, with 50 as a default if you don’t pass any. The impact could be meaningful if you have many routes that were added before the one that you are actually trying to hit, for example, I ran this quick benchmark on my pc, just doing as many requests as possible to importantRoute
router.get("/importantRoute", () => true);
// 14,651,602 ops/sec
And then:
router.get("/a", () => true);
router.get("/b", () => true);
router.get("/c", () => true);
router.get("/d", () => true);
router.get("/e", () => true);
router.get("/f", () => true);
router.get("/g", () => true);
router.get("/h", () => true);
router.get("/importantRoute", () => true);
// 8,846,612 ops/sec
Also, the price of this extra work would be paid only when the routes are being added, most of the time when the server is starting up so it does not really matter if it takes a few milliseconds longer 😃
If you think it’s a good idea I can take a shot at implementing it.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top GitHub Comments
This is where sub-routers/sub-applications come into play. It allows you to have a sort-order for groups and then within groups, and there’s not much of a performance hit anyway - often ends up being faster if you have many routes.
You can think of them as creating a multi-dimensional
routes
array, except that Trouter will only go down a level if the group prefix matches. Effectively allows you to skip chunks of routes.Thanks for the discussion!
Yep, adding them in order is definitely a solution but that way will force the developer to follow that rule and maybe for readability benefits you want to group the endpoints. For example adding all the
user
related endpoint (where only one is frequently used and after that all thecustomers
related endpoint (where again, only one is commonly used). That would be easy to read but not the optimal internal structure. But I do understand your points, I guess I will have to get closer to the metal if I want to squeeze more performance 😊Thank you very much for your time!