Performance of this deep equal implementation is generally proportionally between 5x slower and 700x slower compared to native deepStrictEqual

[unphased]

I have a test implemented here using my test/benchmark library. I've also taken the plot that this generates and hosted it publicly on the net here: https://unphased.github.io/static-sharing/2024-03-29/deepequal_perf/deepequal_perf_collisions.html

I like this method of sharing benchmark results in HTML format since the plot made with uplot allows for interacting with series and zooming in.

The general summary based on the above plotting is that although this deep-equal implementation does not have an asymptotic algorithmic shortcoming compared to the builtin (as demonstrated by the straight lines in the first plot), it is consistently between 5x slower (if I compare large arrays filled with integers) and 700x (!!) slower (if I compare large arrays filled with objects). Obviously being implemented in js as opposed to presumably C++ will necessitate a 2-10x performance hit, something seems suboptimal here because this is a lot slower than that.

I first became aware of the issue being in this library by seeing it show up in the chrome profiler. I haven't reviewed the code yet, but based on the flamegraph that I saw, the implementation appears to be a recursive one. And that doesn't bode well for performance, but I would expect even a recursive implementation to be faster than what I'm seeing.

Please let me know if any of this is unclear.

[ljharb]

If there's a way to maintain correctness and compatibility while increasing performance, I'm all for it.