Why is microdiff faster? better algorithm?

[rjrodger]

Hey - looks cool! Might be useful for a project I'm working on - would be good to understand where the speed comes from?
Thanks!

[AsyncBanana]

Thanks for asking! I would say it is primarily two things.

First, Microdiff is built to be small and fast. For example, many JavaScript diffing libraries split up the diffing of different types like arrays, dates, and objects into separate functions, where Microdiff tries to combine whatever possible. Combining type behaviors can make the code a bit less readable and is harder to do, but it pays off in size and performance.

The second reason is that Microdiff aims for working for 99% of use cases, instead of making every edge case work. This ties into the first reason two, as combining type behaviors can create some odd edge cases, but for most cases, it works fine. I am working on improving behavior with non-primitive types to try to reduce the edge cases without impacting performance much, but Microdiff will never be able to work perfectly with the 1% use case.

I hope this helped! If you have any more questions, feel free to ask!

[AsyncBanana]

If you are still interested, Microdiff now supports more non-primitive types like RegExp, so now many edge cases that it previously did not support now work without impacting performance. Support for non-primitive types is done by combining type behaviors, as I talked about before. However, the new version of Microdiff does this even more, allowing the same code to diff regex, dates, and more in a performant way.

Because of this new release, many of the disadvantages of Microdiff have been removed. However, Microdiff is still a new library, so it might be buggy. There shouldn't be many bugs, though, because smaller codebases generally have fewer bugs, and I am developing a suite of unit tests to ensure that there is no unexpected behavior.

[peey]

@AsyncBanana great benchmarks, and very nice-to-read code as well!

I believe that an explainer (perhaps a blog post?) of the inefficiencies you've noticed with other libraries and how you've overcome them (including the "edge cases" you're saying are unsupported) would be very interesting. They'd also help correctly interpret the benchmark results.

That might in fact also attract more people to switch from those libraries to this one (if that's one of your goals) despite it being very new, because they understand what's going on.

I am developing a suite of unit tests to ensure that there is no unexpected behavior.

I'll also recommend using the cases from test suites of your competing libraries. That should give you excellent coverage.

[AsyncBanana]

Thanks for the suggestions!

I probably will make a blog post soon about creating Microdiff and how I optimized it compared to other libraries.
That is a good idea to use other test suites. I already have a lot of the same tests, and I have looked at other test suites a bit, but I will look at other test suites some more to maximize coverage.

[AsyncBanana]

Closing this because of inactivity and I have answered the original question

[AsyncBanana]

I have now explained this more in depth in Building the fastest object and array differ