c.rubler.net/blog

gix-blame performance improved by a change in gix-diff

2026-03-14T10:45:00+01:00

In February 2026, we got a PR in gitoxide that substantially improved gix-diff’s tree diff performance. Since gix-blame’s algorithm uses a lot of tree diffs under the hood, I wanted to know what the impact on gix-blame’s performance was.

I set up a benchmark using hyperfine in this script and, with the help of seaborn, plotted the results using another script. And the results are quite impressive: speedups of up to 25 % in some scenarios, with no noticeable performance degradation in any scenario.

The comparison was run between this commit that contained the optimization and its parent. The full results can also be found as json files in this gist.

Update 2026-03-14: I’ve changed the plots to use shades of blue instead of variants of magenta and green.

Plots

Catplot of running 2 versions of gix-blame on a set of files

Boxplot of running 2 versions of gix-blame on a set of files

Details for individual benchmark runs

The commands have been shortened. The commit hash is short for a version of gitoxide compiled from that commit. e63d487fb is the commit containing the optimization, 29040a827 is its parent. All runs were regular gix blame … runs.

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 CHANGELOG.md`	137.5 ± 2.7	133.4	143.8	1.00
`e63d487fb CHANGELOG.md`	137.8 ± 2.9	133.4	143.8	1.00 ± 0.03

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 STABILITY.md`	45.8 ± 2.0	42.6	51.1	1.01 ± 0.06
`e63d487fb STABILITY.md`	45.5 ± 1.6	42.0	48.7	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 README.md`	101.0 ± 2.6	95.8	107.2	1.00 ± 0.04
`e63d487fb README.md`	100.8 ± 2.8	95.7	106.2	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 Cargo.toml`	87.3 ± 2.3	82.6	91.5	1.00
`e63d487fb Cargo.toml`	88.1 ± 2.3	83.4	93.1	1.01 ± 0.04

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 gix-blame/src/file/function.rs`	33.2 ± 1.5	30.8	38.0	1.30 ± 0.09
`e63d487fb gix-blame/src/file/function.rs`	25.5 ± 1.3	23.2	28.3	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 gix-path/src/env/mod.rs`	37.2 ± 1.7	34.0	41.9	1.27 ± 0.08
`e63d487fb gix-path/src/env/mod.rs`	29.4 ± 1.3	27.1	32.7	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 gix-index/tests/index/file/write.rs`	55.2 ± 2.3	51.1	59.4	1.29 ± 0.09
`e63d487fb gix-index/tests/index/file/write.rs`	42.7 ± 2.3	38.7	54.3	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 gix-object/src/lib.rs`	76.8 ± 2.3	72.0	81.6	1.07 ± 0.05
`e63d487fb gix-object/src/lib.rs`	71.7 ± 2.8	65.3	77.8	1.00

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
`29040a827 gix-odb/src/store_impls/loose/write.rs`	79.3 ± 2.7	74.5	84.8	1.14 ± 0.06
`e63d487fb gix-odb/src/store_impls/loose/write.rs`	69.6 ± 2.7	64.6	75.0	1.00

gix-blame performance with imara-diff 0.1 and 0.2

2026-01-25T17:44:00+01:00

Recently, we started the process of upgrading gitoxide’s dependency on imara-diff from 0.1.8 to 0.2.0 (tracked in this issue). Because imara-diff’s API has changed significantly, the changes are currently behind a feature flag. What I’ve been wondering, though, is whether this update has any impact on gix-blame’s performance as gix-blame spends a lot of time diffing two versions of a file.

In order to collect some data, I compiled two versions of the gix binary via cargo build --release --features blame-experimental and cargo build --release. Then I used hyperfine to run gix blame on a couple of files in my local copy of the gitoxide repo. The results are below.

It seems that the version using imara-diff 0.2 might have a slight advantage when it comes to files that have changed a lot over the course of this repo’s history, such as CHANGELOG.md or Cargo.toml, but it’s still rather close, so I wouldn’t draw too many conclusions.

Detailed results

❯ env GIT_DIR="$HOME/github/Byron/gitoxide/.git" BASELINE_EXECUTABLE="$HOME/bin/gix-blame-2026-01-25-3b6650a66" COMPARISON_EXECUTABLE="$HOME/bin/gix-blame-experimental-2026-01-25-3b6650a66" just benchmark-gix-blame
hyperfine "${BASELINE_EXECUTABLE} blame CHANGELOG.md" "${COMPARISON_EXECUTABLE} blame CHANGELOG.md"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame CHANGELOG.md
  Time (mean ± σ):     141.6 ms ±   3.3 ms    [User: 100.8 ms, System: 40.7 ms]
  Range (min … max):   133.7 ms … 146.6 ms    21 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame CHANGELOG.md
  Time (mean ± σ):     137.0 ms ±   3.4 ms    [User: 95.7 ms, System: 41.2 ms]
  Range (min … max):   126.5 ms … 142.3 ms    21 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame CHANGELOG.md ran
    1.03 ± 0.04 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame CHANGELOG.md

hyperfine "${BASELINE_EXECUTABLE} blame STABILITY.md" "${COMPARISON_EXECUTABLE} blame STABILITY.md"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame STABILITY.md
  Time (mean ± σ):      43.7 ms ±   2.2 ms    [User: 30.1 ms, System: 13.3 ms]
  Range (min … max):    40.8 ms …  52.5 ms    56 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame STABILITY.md
  Time (mean ± σ):      42.9 ms ±   1.4 ms    [User: 30.1 ms, System: 12.6 ms]
  Range (min … max):    40.8 ms …  47.2 ms    65 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame STABILITY.md ran
    1.02 ± 0.06 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame STABILITY.md

hyperfine "${BASELINE_EXECUTABLE} blame README.md" "${COMPARISON_EXECUTABLE} blame README.md"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame README.md
  Time (mean ± σ):     102.6 ms ±   3.9 ms    [User: 72.9 ms, System: 29.4 ms]
  Range (min … max):    95.0 ms … 109.6 ms    28 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame README.md
  Time (mean ± σ):     102.2 ms ±   2.1 ms    [User: 72.2 ms, System: 29.9 ms]
  Range (min … max):    98.8 ms … 106.7 ms    28 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame README.md ran
    1.00 ± 0.04 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame README.md

hyperfine "${BASELINE_EXECUTABLE} blame Cargo.toml" "${COMPARISON_EXECUTABLE} blame Cargo.toml"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame Cargo.toml
  Time (mean ± σ):      86.3 ms ±   2.7 ms    [User: 61.8 ms, System: 24.3 ms]
  Range (min … max):    81.8 ms …  91.9 ms    34 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame Cargo.toml
  Time (mean ± σ):      82.7 ms ±   2.3 ms    [User: 59.7 ms, System: 22.8 ms]
  Range (min … max):    79.7 ms …  90.2 ms    34 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame Cargo.toml ran
    1.04 ± 0.04 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame Cargo.toml

hyperfine "${BASELINE_EXECUTABLE} blame gix-blame/src/file/function.rs" "${COMPARISON_EXECUTABLE} blame gix-blame/src/file/function.rs"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-blame/src/file/function.rs
  Time (mean ± σ):      31.6 ms ±   1.6 ms    [User: 21.7 ms, System: 9.7 ms]
  Range (min … max):    29.6 ms …  38.0 ms    77 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-blame/src/file/function.rs
  Time (mean ± σ):      31.3 ms ±   0.9 ms    [User: 20.8 ms, System: 10.4 ms]
  Range (min … max):    29.6 ms …  34.6 ms    93 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-blame/src/file/function.rs ran
    1.01 ± 0.06 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-blame/src/file/function.rs

hyperfine "${BASELINE_EXECUTABLE} blame gix-path/src/env/mod.rs" "${COMPARISON_EXECUTABLE} blame gix-path/src/env/mod.rs"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-path/src/env/mod.rs
  Time (mean ± σ):      35.7 ms ±   2.7 ms    [User: 25.3 ms, System: 10.0 ms]
  Range (min … max):    32.5 ms …  50.9 ms    58 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-path/src/env/mod.rs
  Time (mean ± σ):      35.4 ms ±   2.0 ms    [User: 25.2 ms, System: 10.1 ms]
  Range (min … max):    32.6 ms …  43.4 ms    79 runs

Summary
  /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-path/src/env/mod.rs ran
    1.01 ± 0.10 times faster than /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-path/src/env/mod.rs

hyperfine "${BASELINE_EXECUTABLE} blame gix-index/tests/index/file/write.rs" "${COMPARISON_EXECUTABLE} blame gix-index/tests/index/file/write.rs"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-index/tests/index/file/write.rs
  Time (mean ± σ):      53.2 ms ±   2.6 ms    [User: 40.1 ms, System: 12.8 ms]
  Range (min … max):    49.0 ms …  63.0 ms    47 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-index/tests/index/file/write.rs
  Time (mean ± σ):      53.3 ms ±   2.5 ms    [User: 40.8 ms, System: 12.3 ms]
  Range (min … max):    49.1 ms …  60.5 ms    58 runs

Summary
  /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-index/tests/index/file/write.rs ran
    1.00 ± 0.07 times faster than /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-index/tests/index/file/write.rs

hyperfine "${BASELINE_EXECUTABLE} blame gix-object/src/lib.rs" "${COMPARISON_EXECUTABLE} blame gix-object/src/lib.rs"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-object/src/lib.rs
  Time (mean ± σ):      75.6 ms ±   2.8 ms    [User: 56.9 ms, System: 18.4 ms]
  Range (min … max):    71.4 ms …  82.1 ms    37 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-object/src/lib.rs
  Time (mean ± σ):      76.5 ms ±   2.9 ms    [User: 59.2 ms, System: 17.0 ms]
  Range (min … max):    71.6 ms …  82.7 ms    39 runs

Summary
  /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-object/src/lib.rs ran
    1.01 ± 0.05 times faster than /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-object/src/lib.rs

hyperfine "${BASELINE_EXECUTABLE} blame gix-odb/src/store_impls/loose/write.rs" "${COMPARISON_EXECUTABLE} blame gix-odb/src/store_impls/loose/write.rs"
Benchmark 1: /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-odb/src/store_impls/loose/write.rs
  Time (mean ± σ):      75.1 ms ±   2.3 ms    [User: 58.8 ms, System: 16.0 ms]
  Range (min … max):    70.4 ms …  81.3 ms    36 runs

Benchmark 2: /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-odb/src/store_impls/loose/write.rs
  Time (mean ± σ):      77.1 ms ±   3.2 ms    [User: 60.1 ms, System: 16.9 ms]
  Range (min … max):    70.8 ms …  82.3 ms    37 runs

Summary
  /home/christoph/bin/gix-blame-2026-01-25-3b6650a66 blame gix-odb/src/store_impls/loose/write.rs ran
    1.03 ± 0.05 times faster than /home/christoph/bin/gix-blame-experimental-2026-01-25-3b6650a66 blame gix-odb/src/store_impls/loose/write.rs

Github completion in `nvim` when called by `gh`

2025-10-09T20:36:00+02:00

I frequently use the Github CLI for things like creating PRs (gh pr create) or writing comments on PRs (gh pr comment). In these instances, it is really helpful to have completion for issues and users via blink-cmp-git. For example, if you type #, you get a popup with a list of Github issues, allowing you to easily reference relevant ones without the need to context-switch.

However, I only want completion in very specific circumstances, when nvim is started by gh. While the docs describe how blink-cmp-git can be enabled for all Markdown files, that’s not what I want, as I find completion popups annoying most of the time and want to limit the number of contexts they appear in. So I was looking for a way to enable completion only when nvim is started by gh and came up with the following solution.

First, I configured GH_EDITOR in $HOME/.profile:

# in `$HOME/.profile`
export GH_EDITOR="nvim -c 'lua vim.g.enable_git_completion=true'"

gh reads GH_EDITOR and starts nvim, passing a small piece of Lua that sets a global variable to true. This variable is then read in my Neovim config in order to enable Github completion:

enabled = function()
  return vim.tbl_contains({ "octo", "gitcommit" }, vim.bo.filetype) or vim.g.enable_git_completion == true
end

That way, blink-cmp-git is enabled for filetypes that are very likely related to Github as well as when enable_git_completion is true.

Using SvelteKit’s `resolve` with dynamic paths and parameters

2025-09-15T16:07:00+02:00

I’m just documenting a minor doc issue I had with SvelteKit recently, in order to prevent me from running into it again.

The docs don’t mention that you are not free to choose placeholder names in resolve’s first parameter. In fact, you are constrained to the actual directory structure inside src/routes, a fact that was not immediately obvious to me. While this constraint probably can be inferred from resolve expecting a “route ID” as its first parameter, something that is mentioned in the docs, I still found it confusing.

└── blog
    └── [slug]
        └── +page.svelte

So, given the above directory structure, you’ll need to use resolve('/blog/[slug]', { slug: 'slug' }) while anything else, such as resolve('/blog/[id]', { id: 'id' }), will not work. Instead, TypeScript will give you an error that unfortunately makes it quite hard to figure out the actual problem: Expected 1 arguments, but got 2. The reason for this is that the parameters’ types are conditional on the first parameter being an actually existing route. Only if it is one, resolve will accept a second parameter.

I initially came across this issue as an update to eslint-plugin-svelte came with a new lint rule, svelte/no-navigation-without-resolve, in response to which I rewrote a couple of lines related to generating URLs.

Missing user profile directory in Nix after install

2025-09-12T10:27:00+02:00

Recently, on one of my Ubuntu machines, I decided to start relying on Nix for installing and managing a couple of developers tools I regularly use, such as eza, hyperfine, samply and stylua. Most of these tools are only available in older versions in the Ubuntu package repositories or they’re not available at all, but all are available in fairly recent versions in nixpkgs.

❯ nix-env -q
eza-0.23.1
hyperfine-1.19.0
samply-0.13.1
stylua-2.1.0

I already had an old Nix installation from a couple years back, but it seemed to not be in a good state, at least nix doctor (now nix config check) told me there were a few issues. Unfortunately, nix doctor didn’t tell me how to fix them. In order to reset to a known good state, I decided to reinstall Nix.

The installation went well, except the multi-user installation did not automatically create a profile directory inside /nix/var/nix/profiles/per-user/. This left me with the following error message when trying to install any package:

❯ nix-env -iA nixpkgs.stylua
installing 'stylua-2.1.0'
this path will be fetched (1.94 MiB download, 7.93 MiB unpacked):
  /nix/store/jax2k9jfays63q97kiz52mggswaar8g8-stylua-2.1.0
copying path '/nix/store/jax2k9jfays63q97kiz52mggswaar8g8-stylua-2.1.0' from 'https://cache.nixos.org'...
building '/nix/store/a5wiywv48g255zqql0xcaasr6iikvs6s-user-environment.drv'...
error: opening lock file '/nix/var/nix/profiles/per-user/christoph/profile.lock': No such file or directory

The manual doesn’t mention the need to create a profile directory, so I was a bit unsure as to what the canonical way of fixing this issue was. In the end, I decided to create the missing directory by hand at which point I was able to install packages.

nix/profiles/per-user🔒
❯ ls -al
drwxr-xr-x - root 11 Sep 20:17 root

nix/profiles/per-user🔒
❯ sudo mkdir christoph

nix/profiles/per-user🔒
❯ sudo chown $USER: christoph/

nix/profiles/per-user🔒
❯ ls -al
drwxr-xr-x - christoph 11 Sep 20:40 christoph
drwxr-xr-x - root      11 Sep 20:17 root

If it turns out this is the wrong way of fixing things, I’m going to update this post.

Workaround for missing `cargo install –name`

2025-08-30T11:57:00+02:00

Last week, I wanted to install a Rust binary using cargo install, but I wanted to give it a custom name. My specific use case was installing two different versions of the same binary and differentiate them via a suffix, resulting in something like gitui and gitui@v0.27.0.

This doesn’t exist in cargo install yet and it is also not likely to be implemented soon, according to this PR. There’s a quick workaround, though, that I’m documenting here, mostly because I didn’t immediately think of it, instead putting time into following a few of the links in the PR.

# on the branch that’s supposed to supply the unsuffixed binary
❯ cargo install --path .

# and on the branch that’s supposed to result in a suffixed binary
❯ cargo build --release
❯ cp target/release/gitui ~/bin/gitui@v0.27.0

Creating a password using `pass` based on a limited character set

2025-08-29T21:25:00+02:00

Recently, I had to create a new password for a web service that had very restrictive character requirements. Only lowercase letters, uppercase letters, numbers and a few special characters were allowed. Since I couldn’t quickly find a single comprehensive example of how to do this with pass (my password manager), I’m documenting my solution, so that future me can refer back back to it in case the issue comes up again. The solution is based on man pass, but I find the syntax for PASSWORD_STORE_CHARACTER_SET hard to remember, so this should be helpful later.

❯ env PASSWORD_STORE_CHARACTER_SET="[a-zA-Z0-9]\.:@!&,\/;=\\" pass generate example.com 16

Using pass to store a GitHub access token

2022-08-07T21:52:00+02:00

If you want to connect to GitHub using HTTPS, you need an access token. You can store that token in pass and use the following snippet to make git ask pass for the token. I put the snippet into .config/git/user and include that file in my main .gitconfig. This example uses pass, but you can replace the call with anything you like.

# It is necessary to quote the command and escape any double quotes it contains
# (the example at [1] does not do that).
#
# [1]: https://git-scm.com/docs/api-credentials#_credential_helpers
[credential "https://github.com"]
  username = …
  helper = !"f() { echo \"password=`pass access-tokens/github.com`\"; }; f"

elm-logo can solve the Towers of Hanoi problem

2022-07-18T20:42:00+02:00

This is another post about elm-logo being able to run an algorithm from Rosetta Code although this post comes a bit late like the previous one since the required features landed quite a while ago. This time, it is the Towers of Hanoi problem.

to move :n :from :to :via
  if :n = 0 [stop]
  move :n-1 :from :via :to
  (print [Move disk from] :from [to] :to)
  move :n-1 :via :to :from
end
move 4 "left "middle "right

Open snippet in elm-logo (in elm-logo, click “Run” to run it)

elm-logo can draw a fractal tree

2022-07-18T17:01:00+02:00

This post comes a bit late, but since quite a while elm-logo has all the features reqired to draw a fractal tree using this algorithm from Rosetta Code (only pendown was added).

to tree :depth :length :scale :angle
  if :depth=0 [stop]
  setpensize round :depth/2
  forward :length
  right :angle
  tree :depth-1 :length*:scale :scale :angle
  left 2*:angle
  tree :depth-1 :length*:scale :scale :angle
  right :angle
  back :length
end

clearscreen
pendown
tree 10 80 0.7 30

Open snippet in elm-logo (in elm-logo, click “Run” to run it)