url: don't update URL immediately on update to URLSearchParams

[MattIPv4]

This removes the performance impact caused by updating URL when interacting with URL.searchParams, moving that cost to the first access of URL.search, URL.href, URL.toString(), or URL.toJSON(), or to the first update of any part of the URL.

Fixes: #51518

[nodejs-github-bot]

Review requested:

• @nodejs/url

[MattIPv4]

tools/test.py wpt/test-url passes locally with the tweaks in b0270bc 🎉

[anonrig]

WPT tests can't be changed. I recommend changing them on upstream if you think there is a bug.

[MattIPv4]

Ah, hm. That might explain why this is implemented the rather inefficient way it is currently then, as href has to be stored as it was originally passed, even though properly stringified it is something different.

[MattIPv4]

I've asked in the WPT Matrix as to why those tests expect the encoding to behave the way it does, but I believe this push should achieve the same performance benefit while only switching to URLSearchParams once they've actively been updated.

[MattIPv4]

Added a little benchmark, very open to suggestions on if there is a better way to do that. It seems to show a marked improvement with this fix though:

~/GitHub/nodejs/node url-searchparams-perf ?1 ❯ node v21.6.0 ~/GitHub/nodejs/node url-searchparams-perf ?1 ❯ node benchmark/url/url-searchparams-append.js url/url-searchparams-append.js n=1000 type="URL": 14,406.618538860292 ... doesn't progress after 30m 

~/GitHub/nodejs/node url-searchparams-perf !1 ❯ out/Release/node -v v22.0.0-pre ~/GitHub/nodejs/node url-searchparams-perf !1 ❯ out/Release/node benchmark/url/url-searchparams-append.js url/url-searchparams-append.js n=1000 type="URL": 2,437,045.0341551863 url/url-searchparams-append.js n=1000000 type="URL": 9,538,473.063871915 url/url-searchparams-append.js n=1000 type="URLSearchParams": 4,736,530.491415039 url/url-searchparams-append.js n=1000000 type="URLSearchParams": 10,762,833.70515695 

[MattIPv4]

Also, included a benchmark to check that the added logic in #updateContext when searchParams has been used isn't going to impact performance drastically.

~/GitHub/nodejs/node url-searchparams-perf ❯ node -v v21.6.0 ~/GitHub/nodejs/node url-searchparams-perf ❯ node benchmark/url/url-searchparams-update.js url/url-searchparams-update.js n=1000000 property="pathname" searchParams="true": 3,393,713.6186052123 url/url-searchparams-update.js n=1000000 property="search" searchParams="true": 2,755,369.9839588143 url/url-searchparams-update.js n=1000000 property="pathname" searchParams="false": 3,645,786.3368688347 url/url-searchparams-update.js n=1000000 property="search" searchParams="false": 3,485,167.052351517 

~/GitHub/nodejs/node url-searchparams-perf ❯ out/Release/node -v v22.0.0-pre ~/GitHub/nodejs/node url-searchparams-perf ❯ out/Release/node benchmark/url/url-searchparams-update.js url/url-searchparams-update.js n=1000000 property="pathname" searchParams="true": 3,687,806.8658666275 url/url-searchparams-update.js n=1000000 property="search" searchParams="true": 2,727,997.506610279 url/url-searchparams-update.js n=1000000 property="pathname" searchParams="false": 3,526,772.9128872664 url/url-searchparams-update.js n=1000000 property="search" searchParams="false": 3,436,533.8775657485 

[nodejs-github-bot]

Landed in 925a464

[MattIPv4]

Should I have squashed the commits here before they were merged? I notice the commit into main uses the commit message of the first commit here, rather than the PR title, which results in what is now a bit of a misleading commit message?

[aduh95]

Should I have squashed the commits here before they were merged? I notice the commit into main uses the commit message of the first commit here, rather than the PR title, which results in what is now a bit of a misleading commit message?

Yeah the CQ when used with commit-queue-squashAdd this label to instruct the Commit Queue to squash all the PR commits into the first one. always takes the commit message from the first commit. IMO it would make sense if we added some check if the PR title doesn't match to ask what to do, we'd just need someone to volunteer to set it up.

[MattIPv4]

Ah okay, TIL! Is the not-particularly-accurate commit message in main worth worrying about (might be confusing, esp. for the changelogs etc.)?

[aduh95]

It's unfortunate, but we're way passed the 10 minute window, so the commit will stay as is. It might be worth opening a PR backporting it to 21.x-staging branch with the correct commit message (since that's the commits on that branch that actually end up on the changelog).

node/doc/contributing/collaborator-guide.md

Lines 775 to 777 in 62fc950

	messages. You are only allowed to force push to any Node.js branch within 10
	minutes from your original push. If someone else pushes to the branch or the
	10-minute period passes, consider the commit final.

[MattIPv4]

Ack, no worries. I'll look at getting a backport up for 21.x (and ideally 20.x as well).

[MattIPv4]

Would someone be able to add the backport open label for 21.x here, please? ❤️

[aduh95]

(and ideally 20.x as well)

It might not be necessary, IIRC releasers will cherry-pick all the commits from the 21.x branch to the 20.x-staging after the maturation period (unless the commit is linked to a PR with a dont-land-on-20.x or something like that). You could ask for guidance to whoever merges your 21.x backport, as having to deal with a backport PR is more work than simple cherry-picking (both for you and the releaser).

[MattIPv4]

Filed some issues w/ browsers etc. for the same performance issue, as this fix seems to have worked for Node.js w/o issue (knock on wood):

• 🐛 Bug Report — Runtime APIs: URL.searchParams performance issue cloudflare/workerd#1903
• https://bugzilla.mozilla.org/show_bug.cgi?id=1887997
• https://issues.chromium.org/issues/331406951
• https://bugs.webkit.org/show_bug.cgi?id=271735