util: expose toUSVString

[ronag]

Expose toUSVString to it can be used by user libraries.

Refs: nodejs/undici#986

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/39603/

[mcollina]

+1 this needs docs

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/39606/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/39615/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/39624/

[lpinca]

Landed in 82ae00c.

[mathiasbynens]

Suggested change

	/(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])/;
	/\p{Surrogate}/u;

[mathiasbynens]

Patch: #39891

[lpinca]

I tried both this and negative lookbehind but they are slower.

import Benchmark from 'benchmark';

const re1 =
  /(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])/;
const re2 =
  /(?<![\uD800-\uDBFF])[\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])/;
const re3 = /\p{Surrogate}/u;

const str = 'foo bar baz qux\uD800';

const suite = new Benchmark.Suite();

suite.add('re1', function () {
  re1.exec(str);
});

suite.add('re2', function () {
  re2.exec(str);
});

suite.add('re3', function () {
  re3.exec(str);
});

suite.on('cycle', function (event) {
  console.log(String(event.target));
});

suite.on('complete', function () {
  console.log('Fastest is ' + this.filter('fastest').map('name'));
});

suite.run({ async: true });

re1 x 11,864,933 ops/sec ±1.84% (87 runs sampled)
re2 x 8,003,257 ops/sec ±1.38% (90 runs sampled)
re3 x 7,856,998 ops/sec ±1.54% (88 runs sampled)
Fastest is re1

[mathiasbynens]

It’s currently slower for the one specific scenario you’re testing, yes. Change the test string to something like:

const str = 'foo bar baz qux\uD800 foo \uDBFF foo \uDC00 foo \uDFFF';

…and now re3 is the second fastest:

re1 x 12,680,512 ops/sec ±0.75% (89 runs sampled)
re2 x 8,116,354 ops/sec ±0.68% (86 runs sampled)
re3 x 8,460,972 ops/sec ±3.11% (89 runs sampled)
Fastest is re1

Change it to

const str = '\uD800_\uDC00 foo \uD800 foo \uDBFF foo \uDC00 foo \uDFFF';

…and now re3 wins the race:

re1 x 22,303,784 ops/sec ±0.57% (89 runs sampled)
re2 x 21,924,367 ops/sec ±0.56% (86 runs sampled)
re3 x 23,288,295 ops/sec ±0.91% (87 runs sampled)
Fastest is re3

It’s possible to construct a benchmark that shows any three options as the “fastest”, but I don’t think it’s very meaningful.

[lpinca]

and now re3 wins the race

by a tiny margin and I think because the surrogate is at the beginning of the string.

[ronag]

IMHO, we should optimize for the case where there are no surrogates. We could even have false positives if that helps with performance since this is just an optimization to avoid calling into native code.

[lpinca]

A benchmark where re3 is the fastest option by 2%? 4%? 10%

A benchmark where re3 is the fastest by 100%.

These are artificially constructed microbenchmarks, not real-world benchmarks. IMHO any of the three options seems fine from a performance perspective, and given that, we might as well go with the most readable & idiomatic option.

I agree, no one will notice this in a real world application but switching to a slower option for a minor readability improvement seems a bit silly to me. The original regex is not that complex. Also, fwiw, I think re2 is the most readable / easier to grok.

[mathiasbynens]

IMHO, we should optimize for the case where there are no surrogates.

@ronag I tend to agree — that’s probably the common case. All three solutions perform similarly in this case:

const str = 'a'.repeat(1024 * 1024);

re1 x 48,489,097 ops/sec ±2.01% (92 runs sampled)
re2 x 47,831,569 ops/sec ±0.67% (89 runs sampled)
re3 x 48,501,127 ops/sec ±0.68% (89 runs sampled)
Fastest is re3

Do we all agree that all other things equal, \p{Surrogate} is the simplest, most readable pattern? Because in that case, this discussion becomes a matter of choosing which specific use case we optimize for: the one from @lpinca’s benchmark (lone lead surrogate at the end of a short string) or the one from mine (lone trail surrogate at the start of a short string). I think both are edge cases, and I doubt one is more common than the other.

A benchmark where re3 is the fastest option by 2%? 4%? 10%

A benchmark where re3 is the fastest by 100%.

@lpinca So you’d reject a readability improvement unless it also happens to double performance? Woah, that’s a high bar :)

[lpinca]

Yes, a 2x performance drop does not justify a minor readability improvement in my opinion. Anyway I'm not blocking #39891. Just wanted to report this because I tried with the negative lookbehind regex (re2) some time ago and decided to not open a PR because it was slower.

[lpinca]

So you’d reject a readability improvement unless it also happens to double performance? Woah, that’s a high bar :)

FWIW I would be happy with this readability improvement if performance was more or less the same for all inputs. This seems to be the case only for some inputs. Some inputs show a 100% performance drop, in those cases I would like to see a 100% improvement. I don't want it to be always 100% faster. If performance is the same ± 10% for all inputs, then that's great.

[mathiasbynens]

Ideally we’d test lone lead surrogates, lone trail surrogates, and also surrogate pairs (to ensure those are unaffected). Patch: #39891