When do we know if some API is finalised or when it is subject to change?

[jakewilliami]

When do we know if some gix library API is finalised, or when it is subject to change?

I'm picking up an old PR I was working on at the end of last year, and went to upgrade gix (I'm having performance issues and the bottleneck is gix so I was hoping that upgrading might help), but I had to fix some things that were broken in the code: jakewilliami/gl@b2d0193

Of course, these are small changes, but it would be good to know when breaking changes might occur.

My assumption is that perhaps the gix library shouldn't actually be used until v1 is released?

---

P.S., If you were interested in my performance issues, I am currently trying to use gix as the core library of a project. Previously this used a subprocess to git (not libgit2, just the git CLI! 🤮) and a lot of regex. The bottleneck in this version, and a certain task I was benchmarking would take ∼35 ms.

With gix v0.67.0, this was benchmarking at ∼55 ms! Somehow 20 ms slower than the subprocess version.

After upgrading to gix v0.73.0, it's now benchmarking at ∼17 ms—and I haven't made any optimisations to my code, yet.

I'm not entirely sure what changed, because in both versions, the main bottleneck is <gix::revision::walk::iter_impl::Walk as core::iter::traits::iterator::Iterator>::next. But thanks 😄

[Byron]

A fair question :).

Of course, these are small changes, but it would be good to know when breaking changes might occur.

Every gix release comes with breaking changes somewhere, but they are usually small and I don't lightheartedly break major pieces of the API. For the most part, a breaking semver release means it's technically breaking, but most of downstream won't notice.

My assumption is that perhaps the gix library shouldn't actually be used until v1 is released?

It's pre-release software and will remain that for a while. In practice, I don't think this is an issue in this particular case.

After upgrading to gix v0.73.0, it's now benchmarking at ∼17 ms—and I haven't made any optimisations to my code, yet.

There were a bunch of Cargo features one could tune go get a faster ZLIB implementation, but with the arrival of zlib-rs one will always get the fastest one without compromise. Maybe that's the reason.

[jakewilliami]

Thanks Sebastian, thank makes sense!

Wow, I think you're right. That's an incredible speed increase. At v0.67.0, a large majority of the CPU time was taken up by various miniz_oxide::inflate functions. However, at v0.73.0, this is now handled by zlip_rs::inflate functions. Although this is still the majority of the CPU time, this is demonstrably much faster 🙂