Performance issue with URL.searchParams.append for large numbers of params about node

[MattIPv4]

(unrelated to Node.js, but bonus points to anyone that feels like surfacing a similar fix with browser engines, as they seem to suffer from the same bottleneck)

[MattIPv4]

As I understand it currently, URL stores its entire value in #context.href as a single string (and associated pointers for search etc.). When instantiated, URL does not have an associated URLSearchParams. If, and only if, a user accesses searchParams on URL, then a URLSearchParams is instantiated for the URL. However, URL still relies on its own #context.href value always, and so the data in URLSearchParams is essentially a duplicate, and any update to it needs to call the search setter on URL so that #context.href can be updated properly.

Thinking through this, I think the approach to fixing this might be:

• Remove the URL #context from URLSearchParams, so it is a properly independent data store
• Update the search + href getters in URL to interface with searchParams if it exists
• Update the search + href setters in URL to interface with searchParams if it exists, and not pass any search to the internal #context.href, so it is just stored in searchParams (or, rather, update #updateContext to slice the returned href and not store the search index when searchParams exists)
• Update searchParams so that when it instantiates URLSeachParams, it also removes any search from the internal #context.href, so it is just stored in searchParams (probably via the same #updateContext modification)

This does mean that the internal #context.href value of URL will not contain the search string once searchParams has been accessed, but I think that is probably the best thing to do so there is no risk of future confusion with the state of that being potentially out of sync with searchParams.

[benjamingr]

@anonrig @nodejs/performance