perf(ext/url): optimize UrlParts op serialization

[AaronO]

Marshalling it across the op-layer by joining the substrings into a single "fat" newline-joined string, then splitting JS side.

This shaves off a little over a 1/3 of the overhead per call:
main (after merging #11763)

bench:   3,726,203 ns/iter (+/- 177,656)

this PR:

bench:   2,400,289 ns/iter (+/- 53,911)

So with this PR and #11763 that's a combined improvement of over 2x ! (~5000ns/call => ~2400ns/call)

Whilst this might appear counterintuitive and "hacky", it works because:

• We have 11 string values to return
• Marshalling them in a struct creates an obj + 11 optimized/internalized strings (the keys) + 11 unoptimized "normal" strings (the values) + 11 owned strings in Rust
• This approach creates 1 fat owned string in rust, then resplitting it in JS creates 11 efficient substrings (that aren't individually allocated and refer to the fat string)
• \n is a safe separator because it's not allowed in URLs, technically could have used any control char but \n works and is familiar

[satyarohith]

quirks::origin returns a String

[lucacasonato]

Have you considered making UrlParts into strurct UrlParts(Url), and then implementing serde::Serialize on it manually? All the serialization logic could be abstracted into the serializer.

LGTM though.

[AaronO]

Have you considered making UrlParts into strurct UrlParts(Url), and then implementing serde::Serialize on it manually? All the serialization logic could be abstracted into the serializer.

LGTM though.

Yes, I patched the url crate so that it exposes its internal offsets. That's a more efficient serialization that I've prototyped locally, but it either requires patching url or doing pointer arithmetic to recompute those internal offsets.

This PR shaves off over 33% of the call overhead whilst being conceptually simple.