Hi @pimlie!

Can you explain the locale issue in more detail? What did you see to what did you expect.

default x 91,998 ops/sec ±0.96% (88 runs sampled)
sync x 91,686 ops/sec ±1.01% (86 runs sampled)
async x 85,670 ops/sec ±1.71% (89 runs sampled)
async resolve x 80,033 ops/sec ±0.72% (84 runs sampled)
Fastest is default,sync

Hi @jdalton, thanks for getting back to me on this. The above example uses , as thousand-separators. The , seems to be hardcoded in formatNumber. Like other countries, in the Netherlands we use a dot as thousands separator and a comma as decimal separator. So when I see the above numbers my first instinct is to read them as ~90 ops/sec and not ~90000.

It would be nice if this lib could check the env for which numeric locale it should use (eg LC_NUMERIC) and automatically apply correct thousand separators for that locale. For nl_NL the above example would then read as

default x 91.998 ops/sec ±0,96% (88 runs sampled)

Ah nice! Are you familiar with the Intl APIs?

I have looked at Node's Internationalization support but Number.toLocaleString seems not to be locale-aware without re-compiling Node which seems a bit excessive for 'just' changing the number separators.

I'm up for a PR that enhances Intl when possible, so an optional install and a code path for toLocaleString would be great!

Moved to #216 💪