Benchmark alternate malloc implementations (jemalloc, scudo)

[joshtriplett]

Given that gitoxide is allocating memory and working across many threads, it would be worthwhile to benchmark using alternate memory allocators.

It'd be trivial to test jemalloc: just use the jemallocator crate from the top-level gitoxide bin crate, following the instructions in its README.

The scudo allocator has even more performance, as well as some resilience against some kinds of security-related bugs. See https://expertmiami.blogspot.com/2019/05/what-is-scudo-hardened-allocator_10.html for performance information. However, it isn't packaged for Rust yet, so it won't be quite as easy to try.

[Byron]

Thanks for your input!

And agreed, it's absolutely worth running some experiments.

My goal would be to offer feature toggles to make switching between implementations easier. By the looks of it, it doesn't take much indeed and will play nice with feature toggles as well.

[joshtriplett]

I ran some experiments, and the scudo allocator provided much less performance than that blog post would suggest. jemalloc and mimalloc seem like the primary reasonable options. I'd suggest trying jemallocator and mimallocator, and benchmarking.

[Byron]

Thanks for the update. Till now the only place where a lot of allocations can happen is when owned Objects are created - each field of the decoded object usually results in an allocation.

Whether or not an application runs into issues with that probably depends on the application making the gitoxide top level crate the one where the allocator could make a difference. The only command to date which can allocate a lot is gixp pack-verify --re-encode …, which seems to slow about 30% when using the default allocator.

[rickprice]

Hi Sebastian, would you still like some help with this?
Do we have any tests currently for doing benchmarks?
My work (ActiveState) has time (currently 2 days) every quarter where we can work on projects, and I would like to help move gitoxide forward.

[Byron]

Hi @rickprice, I certainly would love some help and benchmarks have been in my mind for a while now. Thus far, there are experiments which effectively serve as comparisons to libgit2, but there is no benchmark suite yet.

Benchmarks should be done per crate and should probably use criterion to drive them, even though glassbench might also be usable but doesn't yet support throughput, a feature I really like.

That said, benchmarks I am interested in is tree parsing in the git-object crate. It seems to be a big factor in diffing huge trees and it might be worth making this faster. A benchmark is required to drive this forward. More generally speaking, benchmarks for parsing objects and accessing packs would help to guide performance optimizations in areas that really make a difference for gitoxide's overall performance.

[rickprice]

I will see what I can do with git-object today, I should be able to get something bare bones setup so we have a flag on the ground. I will then of course try to move it forward over the ensuing time. Rick

…

On Fri, May 7, 2021 at 12:05 AM Sebastian Thiel ***@***.***> wrote: Hi @rickprice <https://github.com/rickprice>, I certainly would love some help and benchmarks have been in my mind for a while now. Thus far, there are *experiments* which effectively serve as comparisons to libgit2, but there is no benchmark suite yet. Benchmarks should be done per crate and should probably use criterion to drive them, even though glassbench might also be usable but doesn't yet support throughput <Canop/glassbench#1>, a feature I really like. That said, benchmarks I am interested in is tree parsing in the git-object crate. It seems to be a big factor in diffing huge trees and it might be worth making this faster. A benchmark is required to drive this forward. More generally speaking, benchmarks for parsing objects and accessing packs would help to guide performance optimizations in areas that really make a difference for gitoxide's overall performance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHXNTXVLK7QNPCTKML4FIDTMNRHFANCNFSM4P7EQ3CQ> .

[CasperN]

Hello, FYI, I just released Scudo bindings in Rust: https://crates.io/crates/scudo. Its still quite fresh so feedback would be appreciated if you add it to your benchmarks