Clojurians Log v2

@afoltzm Wow, same here 😮

@jakemcc Your articles where very helpful, thanks!

Perhaps try disabling font locking just to see if that makes a difference? I still think there isn't a way to disable computing diffs in the status buffer?

I also experienced some slowness with Magit in my largest repo at work, and read some tips online. Can't remember where I found it, but someone suggested that dropping the tags header helps. I'm not really interested in the tags day-to-day anyway, so I have this in my Magit config:

; Remove tags from status buffer headings to speed up refresh slightly
(remove-hook 'magit-status-sections-hook 'magit-insert-tags-header)

Glad the articles were helpful. Makes the time spent writing that up worthwhile 😂

also, don't forget about git fsmonitor https://github.blog/engineering/improve-git-monorepo-performance-with-a-file-system-monitor/

🙏

how slow?

M-x magit takes 3-4 seconds to build a UI

Staging a hunk takes several seconds

on macos you have to be careful which git binary is used

Never heard of slowness. Maybe some other mode is conflicting? If you have it easy, perhaps try it over a minimal clean Emacs install and a variety of repos

@mpenet I'm on OSX, maybe this is my problem?

could be

Basically, everything takes several seconds

git is installed via brew or dev tools?

Not really sure. Maybe it's just system git? 🤔

/usr/bin/git

which git

hmm don't know then. I just recall that homebrew git was painfully slow

what's the recommended git installation to use?

git --version git version 2.50.1 (Apple Git-155)

that's what I am using, it's fast, even on massive repos

Same

Hmm

FWIW I've always used /opt/homebrew/bin/git with no issue

ymmv I guess

How can I check what git magit is using?

emacs version? native-comp?

Emacs for osx

29.4

> GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.5.0, NS appkit-2575.60 Version 15.5 (Build 24F74)) of 2025-06-06

I am on emacs-plus

never had luck with emacs for osx

but it was a while since I last tried

Oh? I've used it for 10 years with no hiccups

Unless it is the reason why magit is slow 😅

🙂

give it a try, maybe that helps

I have Emacs for OSX. No problems here.

(I'm on 30.1)

I have some corporate bullshit software like Microsoft Defender etc, could that be my problem? It doesn't seem like git is slow in the terminal.

Well magit and emacs on linux for me is faster than magit and emacs on Windows on more powerful hardware (but with Microsoft Defender and a lot of other over-protective stuff on corporate laptops) but I guess that is somewhat expected for emacs on windows.

https://docs.magit.vc/magit/Essential-Settings.html#Performance-1 this might be helpful

here’s what i would check: start up an eshell terminal and type which git i think this will be the one resolved by magit. work on a trivial repo where you know there are no weird commit hooks m-x profiler-start and do a cpu profiling of rendering the magit buffer a few times and see where it’s waiting?

Back when I was working in a large monorepo, I did some digging into what was taking time and tweaked what magit-status UI displays and drastically improved the speed by having it do less work. https://jakemccrary.com/blog/2020/11/14/speeding-up-magit/ with some pointers on that strategy. I can't remember the status of native-comp with the version of emacs you posted but that made a difference as well (different https://jakemccrary.com/blog/2020/12/30/speeding-up-magit-with-the-native-comp-branch-of-emacs/)

Thanks for all the input! There are several things here I'll try.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Customizing-VC.html Double check the value of vc-handled-backends; Git is second-to-last by default! Profiling pointed my in the direction of this var - I've been burned by this in the past and it's a pretty trivial change to make to see if it improves performance

I noticed Magit status buffer taking longer to display after using Emacs with Native Compilation enabled. Once the Magit status buffer was open then it seemed fine. Subsequent opening if Magit Status buffer was slow. I always open magit in a full sxreen buffer.

I've had a similar thing (enter search string, backspace a few times -> hanging) with consult-ripgrep, but still not able to reproduce it reliably. I initially thought it might just be a rg issue in folders with a lot of stuff, but that wasn't it. But the good thing is that I can at least just kill rg and emacs is fine again.

You mean pkill -SIGUSR2 emacs, I hope?

huh, y'know I only vaguely conceptually understand the differences between different kill signals (as in kill-for-sure-right-now vs kill-but-cleanup-after-yourself-first). what's the potential adverse effects/mechanical differences of pkill X vs pkill -SIGUSR2 X? i'm guessing just potential for zombie processes?

the latter doesn't actually kill the process, it sends a signal from the outside that makes Emacs enter a debugger.

oh, i've never tried that before/didn't know it existed; that'll definitely make these less disruptive--if it can break through the freeze at all. appreciate it, I see a recommendation to probably M-x toggle-debug-on-quit immediately after (assuming I get control back) ty monsieur gratitude

it does flip debug-on-quit on - which sometimes is annoying as after you deal with whatever hangs it, you often have to manually flip it off again. I have an alias: alias ,sigusr2='pkill -SIGUSR2 emacs' pro-tip: always start your custom bash functions and aliases prefixed, so you can easily find them. I would type , TAB and see all my customs

it is an absolute lifesaver. I don't remember the last time I actually had to hardkill Emacs process because it decided to hang for a while

oh that is beautiful, and the , prefix is a great strat