need to add equality comparator

[noname0310]

202 line's key !== node.key is acts like a reference comparison for an Object.
so, It is impossible to process a case where an object of the nature of a record is used as a key.

It would be better to add comparator like equalOp?: (a: K, b: K) => boolean in Tree<K, V> constructor parameter.

/** @internal */_findNode(
  key: K,
  node: Node<K, V> = this._root,
): Node<K, V> {
  while (node.ok && key !== node.key)
//                  ^^^^^^^^^^^^^^^^ --- here is problem
    node = this._less(key, node) ? node._left : node._right
  return node
}

[nalply]

Right. It's true that `!==` is not exactly the perfect thing to do because there's `lessOp`, however `lessOp` had a performance price. I am not sure whether `eqOp` would be a better solution, I am sorry. I suggest you fork and try out yourself. Thanks for the report!

…

On Thu, Jan 13, 2022 at 4:53 PM noname ***@***.***> wrote: 202 line's key !== node.key is acts like a reference comparison for an Object. so, It is impossible to process a case where an object of the nature of a record is used as a key. It would be better to add comparator like equalOp?: (a: K, b: K) => boolean in Tree<K, V> constructor parameter. /** @internal */_findNode( key: K, node: Node<K, V> = this._root,): Node<K, V> { while (node.ok && key !== node.key)// ^^^^^^^^^^^ --- here is problem node = this._less(key, node) ? node._left : node._right return node} — Reply to this email directly, view it on GitHub <#9>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABKCAWBVBDEJWS7YAVXNMTUV3YPXANCNFSM5L4HGVTQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[noname0310]

Is there no change in this repository regarding this topic?
If so, it would be better to write down an additional explanation of this problem in the documentation.

• This is my suggestion.

[nalply]

Please try to run a test case with at least a million entries where the `equalOp` is used heavily (by calling `get()`, `set()` and `delete()` many times. Compare the `equalOp` with the `!==` case and see whether there's a big performance degradation. I would like to see the results of both runs. When you do that it's easier for me to see whether `equalOp` causes performance problems. Have a look at Readme.md and click on the profiler output to see what I am writing about.