Vast performance improvements;

[xobotyi]

Reworked all implementations (regular, dedupe, bind). No breaking changes.

Benchmarks:

> node ./benchmarks/run

* local#strings x 15,466,941 ops/sec ±0.36% (92 runs sampled)
*   npm#strings x 3,646,035 ops/sec ±1.69% (88 runs sampled)
* local/dedupe#strings x 2,648,941 ops/sec ±0.19% (93 runs sampled)
*   npm/dedupe#strings x 1,470,214 ops/sec ±1.71% (94 runs sampled)

> Fastest is local#strings

* local#object x 17,545,632 ops/sec ±0.42% (93 runs sampled)
*   npm#object x 3,899,880 ops/sec ±1.32% (93 runs sampled)
* local/dedupe#object x 7,118,462 ops/sec ±0.26% (91 runs sampled)
*   npm/dedupe#object x 2,632,530 ops/sec ±0.16% (94 runs sampled)

> Fastest is local#object

* local#strings, object x 11,379,569 ops/sec ±0.44% (95 runs sampled)
*   npm#strings, object x 3,259,972 ops/sec ±0.40% (94 runs sampled)
* local/dedupe#strings, object x 2,525,953 ops/sec ±1.49% (93 runs sampled)
*   npm/dedupe#strings, object x 1,548,802 ops/sec ±0.14% (92 runs sampled)

> Fastest is local#strings, object

* local#mix x 7,226,283 ops/sec ±0.20% (95 runs sampled)
*   npm#mix x 2,521,931 ops/sec ±1.39% (93 runs sampled)
* local/dedupe#mix x 907,851 ops/sec ±0.39% (93 runs sampled)
*   npm/dedupe#mix x 667,852 ops/sec ±0.84% (95 runs sampled)

> Fastest is local#mix

* local#arrays x 3,571,391 ops/sec ±0.17% (94 runs sampled)
*   npm#arrays x 919,980 ops/sec ±0.22% (91 runs sampled)
* local/dedupe#arrays x 1,028,421 ops/sec ±1.41% (95 runs sampled)
*   npm/dedupe#arrays x 743,585 ops/sec ±0.17% (94 runs sampled)

> Fastest is local#arrays

[JedWatson]

Those are some big improvements to the benchmarks @xobotyi, awesome!

I'm reviewing this now and can't see any issues with merging your changes.

Out of curiosity, would you mind annotating the PR (adding your own review is a good way to do this) with some explanations of why the changes you made improved the performance?

Thanks!

[xobotyi]

Done! Glad i did help😇 (actually first time contributing to such a big, in terms of users, package🤪)

[newyork-anthonyng]

The original implementation did something similar. This PR changed it to the current implementation with arrays. It seemed like readability was the main reason of switching over.

[xobotyi]

@newyork-anthonyng looks kinda weird to me, to speculate readability of code you'll never read with obvious performance tradeoff in main lib usecase👺

Just saying🙊

[dcousens]

Will inspect this soon :+1:

[krawaller]

It very likely won't make a measurable difference, but I'm curious if string constants would be an improvement.

var EMPTY = ''
var SPACE = ' ' // (except regex already called this)
var OBJECT = 'object'
var FUNCTION = 'function'
// ...etc

It might well be that variables perform worse than literals (when not using const) since they are mutable and literals aren't.

[xobotyi]

@krawaller there are no perf improvements if to store them in variables, even more - it can slow down due to disabling the typecheck engine optimisation on rare browsers, for them

typeof a === 'string'

will be faster than

var STR = 'string';
typeof a === STR;

or even

var type = typeof a;
type === 'string'

[krawaller]

Ah, roger that, @xobotyi!

[robertmaier]

Are there any plans to merge this?

[zombieJ]

@JedWatson , ping again. Pls help to review and merge. Thank.

ref: https://github.com/ant-design/ant-design/pull/21440

[resynth1943]

cc: @JedWatson any updates on this, please?

[BleedingDev]

Any updates? Is there anything blocking the perf improvement?

[xobotyi]

@pegak nothing, imo. I can offer you a drop-in replacement https://github.com/xobotyi/cnbuilder