Performance degradation when using many routes in comparison to Nuxt 2 about nuxt HOT 6 OPEN

Thank you - great investigation ❤️

We should probably raise this in vue-router or see if we can pre-calculate any of this. A new router does need to be added as it's possible to manipulate the routes per-request, or add new routes. This was also what we did in Nuxt 2:

https://github.com/nuxt/nuxt/blob/2.x/packages/vue-app/template/index.js#L94-L96

from nuxt.

An update on this issue, I raised the issue in vue-router (vuejs/router#2132) and did an isolated performance comparison (vuejs/router#2132 (comment)) between Vue Router v3 and v4 which confirmed the performance difference.

The maintainer has suggested ways on how the performance can be improved (custom matcher and matcher pre-compilation) so I'm going to do some research and (hopefully) work on a solution soon 😄. If you have thoughts or suggestions on a good way to implement these, feel free to leave them on the issue!

from nuxt.

We do need to create a router per-request. But if there's something preventing it from being garbage collected that should definitely be investigated. Would be worth trying to test without Nuxt via https://stackblitz.com/github/nuxt-contrib/vue3-ssr-starter to see if we can rule out vue-router itself as the issue.

For what it's worth, I'm not seeing a huge memory leak when running the reproduction provided by @BobbieGoede. It basically stays at around ~18Mb heap size on my machine for each siege batch. But happy to look into it a bit more...

from nuxt.

Start a new pull request in StackBlitz Codeflow.

• github-4f1tg8 (Open reproduction)
• github-ibrygb (Open reproduction)

from nuxt.

This issue is affecting the Openverse Nuxt 3 migration. We have around 20 routes multiplied by the number of locales, which is more than 50.

It seems that Nuxt creates a new router per user request.

Each call to createRouter in this plugin also makes vue-router to create a new matcher

https://github.com/vuejs/router/blob/4d3cbf58295055ce045efda13db6a1afd144d172/packages/router/src/matcher/index.ts#L349

When I was researching the memory leak in Openverse Nuxt 3 migration branch, I often saw the matcher object retained.
When would each router created in runtime/plugins/router be garbage collected?

from nuxt.

I have updated your reproduction without Nuxt to generate 1101 pages, you can find it here, note this doesn't accept PATH_MULTIPLIER env variable to adjust the amount of routes generated, change dirCount instead.

Without Nuxt the performance also deteriorates in the same way in proportion to the number of routes, so I think we can assume that changes made between vue-router v3 and v4 have had a large impact on its performance (unless Nuxt 2 didn't recreate a new router on each request).

To me it looks like the main suspect would be insertMatcher as it compares a route matcher with all other matchers for every added route, up until its sorted position has been found which is when it is spliced into place. This happens during router creation while adding all initial routes, it doesn't sound like it would scale well with large amounts of routes (I couldn't find its equivalent in Vue Router v3).

Is it possible for routes to be different at router creation in Nuxt or does this essentially stay the same at the start of each request (route changes happen after creation)? I'll look into potential ways of caching some expensive calculations at router creation.

from nuxt.