Interactive Blame doesn't appear to be as fast as tig or non-interactive git blame

[rnk]

Hi, I came to check out this project because I'm looking for a tool for command line interactive blame. I do a lot of source code archaeology , and I would like a single key-press way to go back to the commit that introduced the line in my cursor. As an LLVM developer, I was super excited to try out a project advertised as "blazing fast Rust". :)

However, I ran gitui blame on llvm-project/llvm/lib/Target/X86/X86ISelLowering.cpp, (helpfully github says "(Sorry about that, but we can’t show files that are this big right now.)") and it's still going as I type out this issue / feature request. This isn't a bug so much as, if you are interested in doing further performance engineering and looking for a workload to benchmark, profile, and optimize, I think you should consider this one.

This source file may be a crime against software engineering, but I will say I've done my part to move code out of it, although it was almost entirely done in self-interest.

[extrawurst]

yeah its a known issue with the underlying git implementation, see #673 and upstream libgit2/libgit2#3027 but I am hopeful that we might soon have a contender with gitoxide to migrate to: GitoxideLabs/gitoxide@6ed9976

[extrawurst]

cc @cruessler is gitoxide on par with libgit2 or better yet? :)

[cruessler]

The latest numbers I have are that gitoxide blame has gotten quite close to git, but hasn’t reached its performance yet. I don’t know about libgit2, but I definitely want to try integrating gitoxide blame into gitui soon to find out. :-)

[extrawurst]

@cruessler close to git means for sure faster than libgit2 as this is a magnitude slower than regular git. Using the gitoxide based one then would be a huge win!!

[cruessler]

That’s great news, and thanks for the info! I’ll move trying this out up in my list of priorities, then!

[extrawurst]

Very promising fresh benchmarks: #2269 (comment)