🐛 Delta is slow at startup (2 seconds)

[Xadeck]

I use delta version 18.0.2 both on my work laptop (Macbook, homebrew version) and on my workstation at work (a modified Debian 6.12.32 maintained by Google for its engineers). On the laptop, time delta shows 68.ms but on my workstation:

The main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#get-started. You can also use delta to diff two files: `delta file_A file_B`.

________________________________________________________
Executed in    2.38 secs    fish           external
   usr time    0.15 secs    1.07 millis    0.15 secs
   sys time    2.24 secs    0.21 millis    2.24 secs

Both laptop and workstation have the same dotrc files, so I'd rule this out. In both cases, I try in a /tmp/test empty directory so that it's not due to some slow mounted filesystem.

Is there sometihng special that delta does at startup, like searching for something, that could explain such a delay (because my workstation would have this something slower to find/access)? Any suggestion on how to investigate?

This makes delta basically unusable.

[dandavison]

Can you try setting either dark=true or light=true? Terminal background color autodetection is the most likely culprit.

[Xadeck]

I should have mentioned that I tried that (reading other bugs related to slowness) with time delta --dark. Still very slow.

[dandavison]

Is it slow with --no-gitconfig? E.g. what do you get for this?

$ time delta --no-gitconfig
The main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#get-started. You can also use delta to diff two files: `delta file_A file_B`.
delta --no-gitconfig  0.01s user 0.03s system 104% cpu 0.035 total

[Xadeck]

That's the right direction. With --no-gitconfig it's fast. I dug a bit, and there are two aspects:

1. in a directory our specially mounted filesystem, where working directories are usually deep and are not git versioned, it seems searching the .gitconfig upward is adding 600ms.

2. I bissected my .gitconfig until I could find that any of the two commented lines adds 2s of slowliness.

[delta]
    navigate = true    # use n and N to move between diff sections
    dark = true
    #side-by-side = true
    hyperlinks = false
    #line-numbers = true
    line-numbers-left-format = "{nm:>3}┊"
    line-numbers-right-format = "{np:>3}│"
    syntax-theme = Solarized (dark)

I wondered if those options require querying the terminal for some information, and maybe Kitty was special. But Xterm also exhibits the issue.

So to summarize, the situation is:

╰─ time delta --no-gitconfig
________________________________________________________
Executed in   15.23 millis    fish           external
   usr time    2.56 millis    1.16 millis    1.41 millis
   sys time   20.89 millis    0.23 millis   20.66 millis

╰─ time delta --no-gitconfig -s 
________________________________________________________
Executed in    2.04 secs    fish           external
   usr time    0.12 secs    0.00 millis    0.12 secs
   sys time    1.92 secs    1.54 millis    1.92 secs

[dandavison]

It's unexpected that delta --no-gitconfig -s is slower on your system. Are you sure that's reproducible? What about if you pipe git diff output into delta -- do you see the same timings then?

(I've converted this issue into a discussion since the cause must be related to your local environment.)

[Xadeck]

I agree it's something with my local environment. What I'm trying to figure out is what is delta doing (searching, querying) so that I can look for thing special in my environment with that.

I don't use delta with git in this scenario. I use it to diff files direct in a non git directory, e.g. delta A.txt B.txt, or with mercurial e.g. hg diff | delta. That's where I noticed the slowness.

I gave a try to getting a trace with samply and updated the profile to https://share.firefox.dev/3VyGAEA. It seems that what takes time is find_calling_process.

[Xadeck]

It must be something with my shell or my environment. I use fish. If I run bash from it, them time delta --no-gitconfig -s is fast. my env are the same in both shell.

[Xadeck]

I finally managed to get a flamegraph with details. This points at calling_process_time. If I change this function's code to always return None and recompile delta, it's fast. So that's indeed the right direction.

The trace shows that sysinfo::traits::SystemExt::refresh_process_specifics is called a lot. I added some logging in refresh_process() which is calling it. In Fish shell:

2025-09-09T11:37:38.803534251+02:00 pid 2086450
2025-09-09T11:37:38.872726837+02:00 pid 1949464
2025-09-09T11:37:38.873682545+02:00 pid 2086449
2025-09-09T11:37:38.874580103+02:00 pid 1949464 fish
2025-09-09T11:37:38.874837891+02:00 pid 1949460
2025-09-09T11:37:38.875006400+02:00 pid 1949460 sshd-session
2025-09-09T11:37:38.875117951+02:00 pid 1949203
2025-09-09T11:37:38.875281070+02:00 pid 2086440
2025-09-09T11:37:39.035410234+02:00 pid 2086441
2025-09-09T11:37:39.195842141+02:00 pid 2086442
2025-09-09T11:37:39.356615455+02:00 pid 2086443
2025-09-09T11:37:39.516142359+02:00 pid 2086444
2025-09-09T11:37:39.676181703+02:00 pid 2086445
2025-09-09T11:37:39.835133911+02:00 pid 2086446
2025-09-09T11:37:39.994143798+02:00 pid 2086447
2025-09-09T11:37:40.153038717+02:00 pid 2086448
2025-09-09T11:37:40.153106756+02:00 pid 2086451
2025-09-09T11:37:40.312236369+02:00 pid 2086452
2025-09-09T11:37:40.472185754+02:00 pid 2086453
2025-09-09T11:37:40.630857971+02:00 pid 2086454
2025-09-09T11:37:40.631633128+02:00 pid 2086455
2025-09-09T11:37:40.632355645+02:00 pid 2086456
2025-09-09T11:37:40.791587892+02:00 pid 2086457
2025-09-09T11:37:40.950730820+02:00 pid 2086458
2025-09-09T11:37:41.109679251+02:00 pid 2086459

In Bash:

2025-09-09T11:38:20.766042999+02:00 pid 2088135
2025-09-09T11:38:20.766907895+02:00 pid 2087311
2025-09-09T11:38:20.811989322+02:00 pid 2088134
2025-09-09T11:38:20.812077559+02:00 pid 2087311 bash
2025-09-09T11:38:20.812190483+02:00 pid 1949464
2025-09-09T11:38:20.812393767+02:00 pid 1949464 fish
2025-09-09T11:38:20.812507262+02:00 pid 1949460
2025-09-09T11:38:20.812671723+02:00 pid 2088125
2025-09-09T11:38:20.812719955+02:00 pid 2088126
2025-09-09T11:38:20.812765110+02:00 pid 2088127
2025-09-09T11:38:20.812809404+02:00 pid 2088128
2025-09-09T11:38:20.812853177+02:00 pid 2088129
2025-09-09T11:38:20.812907850+02:00 pid 2088130
2025-09-09T11:38:20.812952985+02:00 pid 2088131
2025-09-09T11:38:20.812996858+02:00 pid 2088132
2025-09-09T11:38:20.813040431+02:00 pid 2088133
2025-09-09T11:38:20.813085166+02:00 pid 2088134
2025-09-09T11:38:20.813128708+02:00 pid 2088136
2025-09-09T11:38:20.813897142+02:00 pid 2088137
2025-09-09T11:38:20.814651740+02:00 pid 2088138
2025-09-09T11:38:20.814702876+02:00 pid 2088139
2025-09-09T11:38:20.814748603+02:00 pid 2088140
2025-09-09T11:38:20.814793498+02:00 pid 2088141
2025-09-09T11:38:20.814838263+02:00 pid 2088142
2025-09-09T11:38:20.814882316+02:00 pid 2088143
2025-09-09T11:38:20.814925878+02:00 pid 2088144

I need to dig into the heuristic for picking which process to search for, and figure out what's happening. But that will be for later, I already spent too much time on this today.