perf(nuxt): prefer iterating rather than Object.fromEntries

[GalacticHypernova]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Many parts of nuxt require some sort of object manipulation, and therefore use Object.fromEntries and some more filter methods. This, especially in larger inputs, can really slow it down. This PR solves these issues by eliminating unnecessary iterations.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[GalacticHypernova]

Sorry this took so long, personal life has been very demanding!
I would like to hear your opinion on whether this PR should be an "mono-perf PR" and kept around to group all improvements (kind of like a monorepo but in PR form) or separate them by topics (like this one currently is for Object.fromEntries)

[GalacticHypernova]

Thanks for the refactor!
I had planned to do it but got a bit caught up with something, sorry about that 😅
Although I do wonder why with reduce 2 checks were failing...

[GalacticHypernova]

May I ask why the revert? I get that smaller arrays would provide less of a performance improvement, but it's an improvement nonetheless. If anything, we can further improve performance in the small entry in vite as the input is known, so if we just create the object manually we avoid all function calls like map, like so:

const toReplace = {
    "X": "Y"
//...
}
//...
replace({...toReplace})

And I'm not even sure, could the bundles be considered small? Is it not user-input dependant?
(Also I apologize for the bad code indent, doing this on mobile isn't the easiest)

[danielroe]

In the case of the analyse plugin, we are calling Object.entries to get an iterator. It's a one-time call (and only when analysing). And it is more readable.

For the other one, it's also a one-time setup call called when Nuxt starts with a very small number of non-user controlled entries. Also negligible performance difference vs readability.

[GalacticHypernova]

Well, in that case I suppose it's reasonable. Thanks for the feedback!