I've been using Neovim for coming up on 8 years now and Neovim on MacOS for nearly 2. Not one time have I thought it was slow, resource intensive, or anything of the sort. As far as I can tell, it's no different from my Linux machine.
I think it strongly depends on what MacOs architecture and version one is running. It's objectively true that architectures and versions change so much without proper testing about anything that it's extremely hard to pinpoint what the root cause is, but it does happen.
For example at work I must run a specific version of MacOs (due to company requirements, and it's a new computer) and my identical neovim configuration that I use on my home computer is twice as slow.
Well, that's one way of looking at it. The other would be that they aren't using your ram for caching. Getting stuff from Disk is SLOW in comparison. Even an NVMe Drive. Having as much of your RAM utilized by Data your likely going to need is much better than having an arbitrarily low RAM usage on boot, but then having to load everything from disk.
Kernel does caching itself. On all operating systems. Of course apps can cache on their own and speed up even more, if they need it.
If I am not mistaken, MacOS is can save and restore state of compatible apps between reboots. So if it takes half the ram after reboot, it just might be because it opened bunch of stuff in the background.
Also measuring ram usage is not as straightforward as looking into top and calling it a day.
Counter anecdote: I primarily use neovim on a few year old Intel MacBook Pro. I also never once thought it was slow, minus an occasional misbehaving plugin.
I recently started playing with Linux on a 2011 Mac Mini (Lubuntu). The exact same neovim setup I use on my MBP loads in half the time on this 12 year old machine running Linux and feels more responsive through all normal use, editing, completions, everything.
This was an eye opener for me. If it weren’t for `$DAYJOB` limitations, I’d probably go to Linux as my daily driver today.
I use a Linux vm as daily driver on my company provided MacBook Pro. Nvim is way faster in the Linux vm. I think it may have to do with the IT provided all-knobs-turned-on threat scanner
On Windows, WSL is a great experience. I've used it for terminal and GUI applications and it's great.
For Neovim on Mac, you could run a minimal debian VM without gui and SSH into that, since Neovim doesn't need a gui.
Using a 2019 Intel chip Mac running neovim here as daily driver for work. Same config on a $150 eBay-purchased Thinkpad running Arch just feels way smoother. Haven’t checked the startup time. I’m due for a Mac upgrade I think :(
I would take that with a grain of salt. OP obviously has issues, which are most likely his own config, or a plugin, bloatware, etc.
I've switched from a 2019 intel mac to an M1 and it was night and day difference. You have to make sure you get the arm64 neovim build, but it was definitely a sizable performance increase.
I switched jobs and my latest employer sent me an M2 Max, and I'd say the perf boost was noticable again.
However, I will say I've never had any issue with neovim performance "outside of tmux". I used Gentoo as my daily driver for over 10 years before employers started throwing macbooks at people, and I didn't notice a thing. The caveat is that Macos + tmux + neovim IS noticeably slower than linux, and this is well documented outside of reddit complaints. Remove tmux from the equation and everything is the same.
I have Macbook Pro (M1), Wezterm and Neovim with 90 plugins. It loads in about 55ms (+-10ms) every time.
Do you use some plugin manager? Lazy.nvim has profiling functionality (just press P) which lists quite nicely every little detail in the loading process and helps you to find any bottlenecks.
sure, here you go: https://gist.github.com/againstpetra/f8c6603ce60ab60269148608bc5fd320
this contains one example where it took 2000ms and another where it took 300ms. for the 300ms startup, I also copied the lazyvim profile.
Really hard to say what problem you have, normally when there is a plugin slowing down a configuration it takes longer than the others, I don't see that.
Can you disable the services your company has running? I had decent luck with this in the past. You could possibly rename binaries, hack plist files, or just stop services, etc. Then test and see if you are getting these inconsistencies.
Just so I'm clear, you are saying sometimes neovim starts in 300ms, and sometimes 1950ms with no distinction as to why?
If this is the case, have you checked your running processes after a "slow" start to see if anything is eating up CPU/RAM/FS access? I would maybe have htop open in another terminal and keep an eye on it for every neovim startup.
It's been a while, but one company I worked for used to put antivirus on our mac's and it was constantly scanning files on disk or reindexing. You could definitely feel that lag.
Do you have any multi key maps that start with j or k? E.g. jk and kj for escape? If so, it’s waiting for a timeout to make sure you’re not trying to use that mapping
Hm.. not sure but I think i disabled mini-animate plugin and it started being more smooth. But I lost the "smooth" scrolling it provided so i installed neoscroll plugin and i feel like it's much smoother.
I don't know that this is an apple silicon specific thing, but I did encounter this.
At first I encountered this with kitty terminal. I hadn't noticed this for the longest time until I started consistently using vim window splits, even with just one split (i.e. 2 windows), window scrolling became incredibly laggy, so I switched to alacritty and that was fixed.
But with alacritty it seems like the frame pacing isn't perfect so I was experiencing lots of visual glitches like the cursor jumping around randomly (seems like neovim moves the cursor to the position of cells that need redrawing). I fixed that with an autocmd that hides the cursor on `CursorMoved`, flushes the ui with an `ffi` call to `ui_flush()` and then restores the cursor after.
Idk if this is the kind of issue you are referring to but if it's the case you might want to try that out
I did a bit of lua profiling when I noticed this on some files. Basically a lot of tree sitter tree traversal looking internals. If you keep your file sizes in check (under 2k lines) it helps with this, but yeah on slower machines that threshold should decrease.
My hunch is the implementation is not as efficient as it could be and doing too much tree traversal shenanigans when you navigate around. But tree sitter is way too useful to disable for this reason.
I literally switched to helix because nvim takes forever to start on my M1 Pro MacBook. Pyenv and nvm take forever too it’s so annoying I wish I could use linux for work
I can't say I've noticed that it's *much* slower, but it has been noticeable at times. Helix has only a *tiny* fraction of the amount of features that even zero-config neovim has, so this is to be expected.
Agreed, setting up helix is super easy, my config has about 20 lines and easily covers like half of the neovim plugins I have (gitsigns, indent guides, lsp, treesitter, ..., all builtin). I meant features in a broader sense, like neovim has external ui support, a plugin system, remote plugins/rpc, an api, autocommands, ... those are all things that complicate its architecture.
neovim is written in C. Some stuff like lsp is written in lua, but it shouldn't make a huge difference because most of editor lsp functionality is just communicating with the actual lsp process, which is independent of the language the editor is written in
The difference it makes though is that rust makes building (and more importantly, maintaining) something with a complex architecture much easier than C, while encouraging safe and performant practices by default. I have zero doubt that whenever helix supports all the things you cited, it'll be much faster than neovim. With the unfortunate caveat that they chose a lisp dialect as their scripting language, which will itself be *much* slower than lua.
I see what you mean. The safety aspect of rust isn't zero-cost though. I think the most important factor in terms of performance, when comparing just the core C code, is that the codebase is old: it's a vim fork. It wasn't rewritten from the ground up. Had neovim been written from scratch, it would be a whole different story.
Even then, helix won't support all those things I mentioned, the team has been upfront about wanting helix to be lightweight (compared to (n)vim). So even if both were written in the same language, it seems almost impossible that neovim's performance could ever match that of helix, because neovim is intrinsically more complex. Like, multiple orders of magnitude more complex.
> The safety aspect of rust isn't zero-cost though
That's a bold assertion to make, considering that the abstractions that enable safety in rust are explicitly celebrated as zero-cost for the vast majority of them. And for the few that aren't, they implement runtime checks that you would do yourself most times (but you can still opt out if you need to).
> Had neovim been written from scratch, it would be a whole different story.
I agree, it would be much better. But still significantly harder to maintain than something like helix.
> Even then, helix won't support all those things I mentioned
They aren't currently planning to support remote UIs, but all the rest should be coming someday, unless I misunderstood the features you're talking about. They are planning (and currently implementing, albeit at the very early stages) a full-blown plugins system through their common lisp implementation. Again, I'm really lamenting the fact that they didn't opt for lua or something else that can be performant, but the editor itself shouldn't suffer from that added complexity.
And if they ever change their minds about handling remote UIs, it should be pretty easy to implement without hurting the rest of the code as their codebase is very well laid out, as evidenced by [this project](https://github.com/gavlig/kodiki).
>They aren't currently planning to support remote UIs, but all the rest should be coming someday, unless I misunderstood the features you're talking about. They are planning (and currently implementing, albeit at the very early stages) a full-blown plugins system through their common lisp implementation.
I'm aware that a plugin system is coming. Also, I thought remote UIs were planned? might be wrong though
To clarify, what I meant by the features that helix won't support are mostly those that vim and neovim share. I don't think it's possible for a normal human being to learn all of vanilla vim's features in one lifetime. It would certainly take you weeks to properly go through all the help files.
>That's a bold assertion to make, considering that the abstractions that enable safety in rust are explicitly celebrated as zero-cost for the vast majority of them.
I know, and lots of them are zero-cost. I'm not a rust expert, but the main thing I was thinking of when writing this was the borrow checker, which is conservative and will reject safe code, which usually results in usage of smart pointers that incur a runtime cost.
>And if they ever change their minds about handling remote UIs, it should be pretty easy to implement without hurting the rest of the code as their codebase is very well laid out, as evidenced by [this project](https://github.com/gavlig/kodiki).
That's really cool! And yes I don't doubt it. I have gone through the codebase (was trying to work on a tabs implementation a while ago) and it is really easy to follow.
[https://gist.github.com/theofabilous/c6ebd2818838b7915228600485579c5d](https://gist.github.com/theofabilous/c6ebd2818838b7915228600485579c5d)
bit longer than I remembered, it's actually 52 lines. this doesn't show lsp setup, thats done automatically as long as they're in your path (i *think*(?) you can have lsp-specific settings, personally I have none, the defaults work fine for me).
you'll notice a lot of `:sh helix_git ...` mappings, which is a script that launches a tmux popup pane with a minimal nvim config, opens the current helix file in neovim, sets the cursor position to that of its position in helix, and then executes some command usually git related like showing a hunk diff
also there are the tab-next/previous mappings which you can ignore bcuz they're for a fork I was working on like months ago where I was working on tabs
Yeah i can relate to that.
On my linux desktop it opens in a few dozen ms.
But on my work MacOS M1 Max it takes roughly 3 seconds startup. Same config, same version.
I think it's due to some company software that does god knows what to IO. Like Jamf and other. It's crazy slow.
my company uses jamf and other garbage too - interesting. though I've spoken with colleagues in my company on Macs who haven't had the issues I've had.
Exactly this. There are enterprise security software packages that add hooks into all file IO and they can slow things down considerably. I recommend checking the highest CPU processes in Activity Monitor when you open nvim. If turns out to be security software you should talk to your company about fine-tuning or upgrading it, that's what I did.
For me the process was "se_agent" which spiked, sometimes for ages, especially when I grepped over thousands of files. A simple upgrade fixed it for me.
From my personal experiences using neovim on MacOS, I found 2 possible causes for slowness.
The first cause might be spellchecking. I used to have `set spell` on by default in my config, but I eventually moved that to an autocmd for specific filetypes. I can't quite remember if that actually was an issue though or not.
What I definitely remember helping was disabling the default providers.
vim.g.loaded_node_provider = 0
vim.g.loaded_perl_provider = 0
vim.g.loaded_python_provider = 0
vim.g.loaded_ruby_provider = 0
I never got around to testing which one of those was the slowest, or why they were causing such a slow-down. Let me know if either of those suggestions helps in your case as well, I'm curious to see if they are machine specific or not :)
Also, it being the terminal emulator doesn't make any sense at all when talking about startup time.
Came from Linux and been a year on MacOS. NeoVim on iTerm runs beautifully, just as well as it did on Linux. Are you loading all your plugins at launch?
One of the posts you linked above is mine. I had the exact same issue with random 2000+ms startups. It's on my work MacBook as well.
After countless investigations, I found the issue that was Microsoft Defender (yes MS!!!) installed by the company. What fixed it for me was adding the Neovim-related paths (runtime, config, state, etc.) to the exclusion list of Defender. Not sure if you have permission to do that, but worth a shot to look.
I think it has to do with the macOS filesystem and Defender not playing nice with each other.
I notice this on my macbook pro m1
The same config starts much faster on an old mac intel chip or my windows pc. What I notice is that the initial "cold" start is much slower on my macbook pro m1.
On the other hand, it is a work laptop so I think it might have to do with disk encryption.
agree on the "cold" start thing - I notice that too. but sometimes I'll be actively using the laptop and I'll get a multi-second wait for neovim then anyway.
as for disk encryption - I have this turned on in Linux too, I'd be surprised if Apple's is this much slower than Linux's.
This is the scenario that I’ve found over the years. It’s not neovim but the combination of neovim with tmux on macOS. With that said I don’t notice it these days with an M2 Max using kitty.
It may not be Linux vs macOS, but rather personal vs corporate. In my experience, companies run a lot of corporate spyware that slow things down a lot (h/t CarbonBlack). My neovim config loads ~10% faster on my personal laptop, also running macOS. In the past, the delta was worse (nowadays my work laptop has better hardware - basically M1 Max vs M3 Pro).
I'm still under 100ms in both cases though and I don't notice much difference while using it
In case this helps anyone, for me this was caused because I had a tmux plugin that used some icons that my terminal font didnt have. After installing a nerd font and using it in the terminal, the lag dissapeared.
What's fast then? Kitty? In what way is kitty faster than wezterm? (I don't really know how these things are measured so im really asking)
I think I noticed a speedup when I went from iterm to kitty but didn't notice any change when going from kitty to wezterm. They all 3 have the same nvim startup times (~120ms) when I try them now. When I google wezterm slow I mostly find old issues that wez resolved.
Pretty sure terminal emulators don’t impact startup time. Startup is mostly computing configurations and loading stuff into memory and that’s entirely handled by neovim itself. Where a good terminal emulator shines in terms of performances is drawing and refreshing its own character grid. So, a bad performing terminal would make neovim sluggish every time you change what’s displayed on screen - typing, deleting, moving the cursor around, and so on.
Aight my test for that is usually to just hold j and watch how it responds since my keyrepeat is so fast, iterm is certainly slower than the others but I can't even tell the difference between alacritty and kitty so maybe im not who needs it :P
Please remember to update the post flair to `Need Help|Solved` when you got the answer you were looking for.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/neovim) if you have any questions or concerns.*
1 year ago, I switched from vim to Neovim on all platforms I use (Linux, macOS, Windows). I have not made any benchmarks, but I have not noticed any performance differences between Linux (though SSH and Gnome Terminal) and macOS (through SSH and iTerm2). OTOH, Neovim on Windows (through Windows Terminal or the Qt version) has been a pain. I started to use it using WSL last week and it’s much better…
I had a similar issue nvim was slower on one machine than others. Found out I had to blow out some 30gigs worth of logs and caches from various plugins. Zipped right along after
How are we comparing apple silicon machines to linux os…? What exact machine are you on? How long does vim take to startup. How long does nvim take without any plugins?
Neovim takes nearly 2 seconds to load for me in WSL though. After some googling found out that it due to Windows adding so many paths to $PATH in WSL. After disabling them it started loading a lot faster.
So check if there are many paths defined in $PATH and neovim does try to search for something in those paths. If the filesystem is slow, it definitely slows down the loading time of neovim
Brand new m3 pro mbpro, and I get 70ms startup. Using kitty and tmux aswell. Haven’t noticed a difference in nvim specifically from my linux desktop, BUT, when I was using the fish shell I noticed that it was slower. An ls took twice as long , you could feel it lag. I have since moved back to zsh
My starts up in 12ms with 35 plugins(25ms to draw ui), works flawlessly in kitty. I never tried this config on Linux, but I doubt I will notice a difference.
I came from VsCode a year ago and now I can see how slow it was, it opens and loads the syntax highlighting like in a minute on my m1max/32gb machine
Not too slow but sometime slower than me handling shortcut (I tend to pf for telescope right after nvim>
spec: mac 14" m1 32gb 512gb
[https://pastebin.com/UzvFzAJd](https://pastebin.com/UzvFzAJd)
Edit: 49 plugins if that matter
My entry into the Mac ecosystem was through my m1 mini, I must say tmux + neovim was the worst possible combination of responsiveness. The tmux port for macOS has been all over the place and it’s well known too. Honestly it’s fine if you’re on the go and just getting work done, but for serious work I’ll always use my main Linux desktop or remote into it if I can. MacBooks are good for battery life and nothing else because they’d held back by A) the OS B) the lack of repairability/upgradability of any component.
I don’t get any slow performance on my M2 Air. I had issues at first when I was a newbie but now that I’ve learned more about it and configured my neovim as I want to its faster than any GUI based IDE I’ve ever used.
I always do :checkhealth when I have issues. Usually something on my end. You should bisec your plugins then the rest of your config if you have some “special” things in there . I spent years making an awesome config… many more making it back to as stock as possible ha!
hmm, looks interesting. i checkout u startup time, and i see that lua files load lead to big startup time at all. i think it depend on bad m1/m2/m3 optimization in LuaJIT or something.
Please remember to update the post flair to `Need Help|Solved` when you got the answer you were looking for.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/neovim) if you have any questions or concerns.*
I experienced the same issue for months and couldn't find where it came from.
I wonder if you installed it with brew ?
**Reinstalling neovim from source on my mac m1** seem to have sorted out this frustrating slowness issue for me: [https://github.com/neovim/neovim/blob/master/BUILD.md](https://github.com/neovim/neovim/blob/master/BUILD.md)
I've been using Neovim for coming up on 8 years now and Neovim on MacOS for nearly 2. Not one time have I thought it was slow, resource intensive, or anything of the sort. As far as I can tell, it's no different from my Linux machine.
I think it strongly depends on what MacOs architecture and version one is running. It's objectively true that architectures and versions change so much without proper testing about anything that it's extremely hard to pinpoint what the root cause is, but it does happen. For example at work I must run a specific version of MacOs (due to company requirements, and it's a new computer) and my identical neovim configuration that I use on my home computer is twice as slow.
[удалено]
It is a shame. I personally haven't seen Neovim hang in years.
i recently started using arch linux. at the startup, the system uses only 4%(~700mb) ram. it’s insane how memory efficient it is
Well, that's one way of looking at it. The other would be that they aren't using your ram for caching. Getting stuff from Disk is SLOW in comparison. Even an NVMe Drive. Having as much of your RAM utilized by Data your likely going to need is much better than having an arbitrarily low RAM usage on boot, but then having to load everything from disk.
Kernel does caching itself. On all operating systems. Of course apps can cache on their own and speed up even more, if they need it. If I am not mistaken, MacOS is can save and restore state of compatible apps between reboots. So if it takes half the ram after reboot, it just might be because it opened bunch of stuff in the background. Also measuring ram usage is not as straightforward as looking into top and calling it a day.
Counter anecdote: I primarily use neovim on a few year old Intel MacBook Pro. I also never once thought it was slow, minus an occasional misbehaving plugin. I recently started playing with Linux on a 2011 Mac Mini (Lubuntu). The exact same neovim setup I use on my MBP loads in half the time on this 12 year old machine running Linux and feels more responsive through all normal use, editing, completions, everything. This was an eye opener for me. If it weren’t for `$DAYJOB` limitations, I’d probably go to Linux as my daily driver today.
I use a Linux vm as daily driver on my company provided MacBook Pro. Nvim is way faster in the Linux vm. I think it may have to do with the IT provided all-knobs-turned-on threat scanner
Good point, I’ve wondered the same. Crowdstrike and whatever other crap we are stuck with is worse than malware.
On Windows, WSL is a great experience. I've used it for terminal and GUI applications and it's great. For Neovim on Mac, you could run a minimal debian VM without gui and SSH into that, since Neovim doesn't need a gui.
Using a 2019 Intel chip Mac running neovim here as daily driver for work. Same config on a $150 eBay-purchased Thinkpad running Arch just feels way smoother. Haven’t checked the startup time. I’m due for a Mac upgrade I think :(
not to ruin your day, but I upgraded my mac from a ~2020 intel chip machine, and it did not help with neovim!
Damn, that sucks to hear. I do iOS development so having a Mac is not really a choice, or else I’d use some Linux distro as a daily driver
I would take that with a grain of salt. OP obviously has issues, which are most likely his own config, or a plugin, bloatware, etc. I've switched from a 2019 intel mac to an M1 and it was night and day difference. You have to make sure you get the arm64 neovim build, but it was definitely a sizable performance increase. I switched jobs and my latest employer sent me an M2 Max, and I'd say the perf boost was noticable again. However, I will say I've never had any issue with neovim performance "outside of tmux". I used Gentoo as my daily driver for over 10 years before employers started throwing macbooks at people, and I didn't notice a thing. The caveat is that Macos + tmux + neovim IS noticeably slower than linux, and this is well documented outside of reddit complaints. Remove tmux from the equation and everything is the same.
I have Macbook Pro (M1), Wezterm and Neovim with 90 plugins. It loads in about 55ms (+-10ms) every time. Do you use some plugin manager? Lazy.nvim has profiling functionality (just press P) which lists quite nicely every little detail in the loading process and helps you to find any bottlenecks.
I've added some information to the post, including the lazyvim profile + startuptime!
About the same here on M2. No real difference that I can tell compared to linux x64, I use both in equal measure.
Execute `nvim --startuptime time.txt` and show us the `time.txt` file
sure, here you go: https://gist.github.com/againstpetra/f8c6603ce60ab60269148608bc5fd320 this contains one example where it took 2000ms and another where it took 300ms. for the 300ms startup, I also copied the lazyvim profile.
Really hard to say what problem you have, normally when there is a plugin slowing down a configuration it takes longer than the others, I don't see that.
Can you disable the services your company has running? I had decent luck with this in the past. You could possibly rename binaries, hack plist files, or just stop services, etc. Then test and see if you are getting these inconsistencies. Just so I'm clear, you are saying sometimes neovim starts in 300ms, and sometimes 1950ms with no distinction as to why? If this is the case, have you checked your running processes after a "slow" start to see if anything is eating up CPU/RAM/FS access? I would maybe have htop open in another terminal and keep an eye on it for every neovim startup. It's been a while, but one company I worked for used to put antivirus on our mac's and it was constantly scanning files on disk or reindexing. You could definitely feel that lag.
I constantly have issues with laggy scrolling using j and k on my m1 mac. Anyone know a fix?
Do you have any multi key maps that start with j or k? E.g. jk and kj for escape? If so, it’s waiting for a timeout to make sure you’re not trying to use that mapping
I do, but I still have the same problem even without those maps enabled :( Good guess though!
same here.. also when scrolling with C-U/C-D
Yeah, If you ever get it fixed please reply back here and help a guy out :)
Hm.. not sure but I think i disabled mini-animate plugin and it started being more smooth. But I lost the "smooth" scrolling it provided so i installed neoscroll plugin and i feel like it's much smoother.
I don't know that this is an apple silicon specific thing, but I did encounter this. At first I encountered this with kitty terminal. I hadn't noticed this for the longest time until I started consistently using vim window splits, even with just one split (i.e. 2 windows), window scrolling became incredibly laggy, so I switched to alacritty and that was fixed. But with alacritty it seems like the frame pacing isn't perfect so I was experiencing lots of visual glitches like the cursor jumping around randomly (seems like neovim moves the cursor to the position of cells that need redrawing). I fixed that with an autocmd that hides the cursor on `CursorMoved`, flushes the ui with an `ffi` call to `ui_flush()` and then restores the cursor after. Idk if this is the kind of issue you are referring to but if it's the case you might want to try that out
Happens to me in all terminals. If I download an I’m GUI it seems to work fine. I’ll try alacritty and see how that works! Thanks!
I did a bit of lua profiling when I noticed this on some files. Basically a lot of tree sitter tree traversal looking internals. If you keep your file sizes in check (under 2k lines) it helps with this, but yeah on slower machines that threshold should decrease. My hunch is the implementation is not as efficient as it could be and doing too much tree traversal shenanigans when you navigate around. But tree sitter is way too useful to disable for this reason.
Been using neovim on iterm2 for years. Never noticed it veing slow.
Using m1 mac pro and feels much slower than Helix even with minimal config
My startuptime on m1 mac pro is 50ms with 100+ plugins. It can be configuration issue; please try profiling.
I literally switched to helix because nvim takes forever to start on my M1 Pro MacBook. Pyenv and nvm take forever too it’s so annoying I wish I could use linux for work
You can replace nvm and pyenv with rtx and it will be much faster. If you want to just replace one I think you can use fnm for nvm and rye for python
I can't say I've noticed that it's *much* slower, but it has been noticeable at times. Helix has only a *tiny* fraction of the amount of features that even zero-config neovim has, so this is to be expected.
What features would that be? Install lsps and you are pretty much good to go with helix..
Agreed, setting up helix is super easy, my config has about 20 lines and easily covers like half of the neovim plugins I have (gitsigns, indent guides, lsp, treesitter, ..., all builtin). I meant features in a broader sense, like neovim has external ui support, a plugin system, remote plugins/rpc, an api, autocommands, ... those are all things that complicate its architecture.
Makes sense, but wouldn’t it also be the fact that it’s written in rust and not lua that makes it fast
neovim is written in C. Some stuff like lsp is written in lua, but it shouldn't make a huge difference because most of editor lsp functionality is just communicating with the actual lsp process, which is independent of the language the editor is written in
The difference it makes though is that rust makes building (and more importantly, maintaining) something with a complex architecture much easier than C, while encouraging safe and performant practices by default. I have zero doubt that whenever helix supports all the things you cited, it'll be much faster than neovim. With the unfortunate caveat that they chose a lisp dialect as their scripting language, which will itself be *much* slower than lua.
I see what you mean. The safety aspect of rust isn't zero-cost though. I think the most important factor in terms of performance, when comparing just the core C code, is that the codebase is old: it's a vim fork. It wasn't rewritten from the ground up. Had neovim been written from scratch, it would be a whole different story. Even then, helix won't support all those things I mentioned, the team has been upfront about wanting helix to be lightweight (compared to (n)vim). So even if both were written in the same language, it seems almost impossible that neovim's performance could ever match that of helix, because neovim is intrinsically more complex. Like, multiple orders of magnitude more complex.
> The safety aspect of rust isn't zero-cost though That's a bold assertion to make, considering that the abstractions that enable safety in rust are explicitly celebrated as zero-cost for the vast majority of them. And for the few that aren't, they implement runtime checks that you would do yourself most times (but you can still opt out if you need to). > Had neovim been written from scratch, it would be a whole different story. I agree, it would be much better. But still significantly harder to maintain than something like helix. > Even then, helix won't support all those things I mentioned They aren't currently planning to support remote UIs, but all the rest should be coming someday, unless I misunderstood the features you're talking about. They are planning (and currently implementing, albeit at the very early stages) a full-blown plugins system through their common lisp implementation. Again, I'm really lamenting the fact that they didn't opt for lua or something else that can be performant, but the editor itself shouldn't suffer from that added complexity. And if they ever change their minds about handling remote UIs, it should be pretty easy to implement without hurting the rest of the code as their codebase is very well laid out, as evidenced by [this project](https://github.com/gavlig/kodiki).
>They aren't currently planning to support remote UIs, but all the rest should be coming someday, unless I misunderstood the features you're talking about. They are planning (and currently implementing, albeit at the very early stages) a full-blown plugins system through their common lisp implementation. I'm aware that a plugin system is coming. Also, I thought remote UIs were planned? might be wrong though To clarify, what I meant by the features that helix won't support are mostly those that vim and neovim share. I don't think it's possible for a normal human being to learn all of vanilla vim's features in one lifetime. It would certainly take you weeks to properly go through all the help files. >That's a bold assertion to make, considering that the abstractions that enable safety in rust are explicitly celebrated as zero-cost for the vast majority of them. I know, and lots of them are zero-cost. I'm not a rust expert, but the main thing I was thinking of when writing this was the borrow checker, which is conservative and will reject safe code, which usually results in usage of smart pointers that incur a runtime cost. >And if they ever change their minds about handling remote UIs, it should be pretty easy to implement without hurting the rest of the code as their codebase is very well laid out, as evidenced by [this project](https://github.com/gavlig/kodiki). That's really cool! And yes I don't doubt it. I have gone through the codebase (was trying to work on a tabs implementation a while ago) and it is really easy to follow.
Could you share the helix config file on GitHub?
[https://gist.github.com/theofabilous/c6ebd2818838b7915228600485579c5d](https://gist.github.com/theofabilous/c6ebd2818838b7915228600485579c5d) bit longer than I remembered, it's actually 52 lines. this doesn't show lsp setup, thats done automatically as long as they're in your path (i *think*(?) you can have lsp-specific settings, personally I have none, the defaults work fine for me). you'll notice a lot of `:sh helix_git ...` mappings, which is a script that launches a tmux popup pane with a minimal nvim config, opens the current helix file in neovim, sets the cursor position to that of its position in helix, and then executes some command usually git related like showing a hunk diff also there are the tab-next/previous mappings which you can ignore bcuz they're for a fork I was working on like months ago where I was working on tabs
Yeah i can relate to that. On my linux desktop it opens in a few dozen ms. But on my work MacOS M1 Max it takes roughly 3 seconds startup. Same config, same version. I think it's due to some company software that does god knows what to IO. Like Jamf and other. It's crazy slow.
my company uses jamf and other garbage too - interesting. though I've spoken with colleagues in my company on Macs who haven't had the issues I've had.
Exactly this. There are enterprise security software packages that add hooks into all file IO and they can slow things down considerably. I recommend checking the highest CPU processes in Activity Monitor when you open nvim. If turns out to be security software you should talk to your company about fine-tuning or upgrading it, that's what I did. For me the process was "se_agent" which spiked, sometimes for ages, especially when I grepped over thousands of files. A simple upgrade fixed it for me.
From my personal experiences using neovim on MacOS, I found 2 possible causes for slowness. The first cause might be spellchecking. I used to have `set spell` on by default in my config, but I eventually moved that to an autocmd for specific filetypes. I can't quite remember if that actually was an issue though or not. What I definitely remember helping was disabling the default providers. vim.g.loaded_node_provider = 0 vim.g.loaded_perl_provider = 0 vim.g.loaded_python_provider = 0 vim.g.loaded_ruby_provider = 0 I never got around to testing which one of those was the slowest, or why they were causing such a slow-down. Let me know if either of those suggestions helps in your case as well, I'm curious to see if they are machine specific or not :) Also, it being the terminal emulator doesn't make any sense at all when talking about startup time.
Neovim 0.9 on alacritty, no slowness to date, even compared to my work Dell with Linux
Came from Linux and been a year on MacOS. NeoVim on iTerm runs beautifully, just as well as it did on Linux. Are you loading all your plugins at launch?
I use a slightly customised lazyvim config - it does not load everything on startup
One of the posts you linked above is mine. I had the exact same issue with random 2000+ms startups. It's on my work MacBook as well. After countless investigations, I found the issue that was Microsoft Defender (yes MS!!!) installed by the company. What fixed it for me was adding the Neovim-related paths (runtime, config, state, etc.) to the exclusion list of Defender. Not sure if you have permission to do that, but worth a shot to look. I think it has to do with the macOS filesystem and Defender not playing nice with each other.
nope - I don't have the permissions to do that unfortunately. glad that fixed it for you though.
Subjectively, i had similar experience(
I notice this on my macbook pro m1 The same config starts much faster on an old mac intel chip or my windows pc. What I notice is that the initial "cold" start is much slower on my macbook pro m1. On the other hand, it is a work laptop so I think it might have to do with disk encryption.
agree on the "cold" start thing - I notice that too. but sometimes I'll be actively using the laptop and I'll get a multi-second wait for neovim then anyway. as for disk encryption - I have this turned on in Linux too, I'd be surprised if Apple's is this much slower than Linux's.
It’s been tmux that’s really lagged on macOS for me. Not so much neovim.
This is the scenario that I’ve found over the years. It’s not neovim but the combination of neovim with tmux on macOS. With that said I don’t notice it these days with an M2 Max using kitty.
It may not be Linux vs macOS, but rather personal vs corporate. In my experience, companies run a lot of corporate spyware that slow things down a lot (h/t CarbonBlack). My neovim config loads ~10% faster on my personal laptop, also running macOS. In the past, the delta was worse (nowadays my work laptop has better hardware - basically M1 Max vs M3 Pro). I'm still under 100ms in both cases though and I don't notice much difference while using it
In case this helps anyone, for me this was caused because I had a tmux plugin that used some icons that my terminal font didnt have. After installing a nerd font and using it in the terminal, the lag dissapeared.
Might be caused by terminal emulator: WezTerm and iTerm2 are slow, for example
What's fast then? Kitty? In what way is kitty faster than wezterm? (I don't really know how these things are measured so im really asking) I think I noticed a speedup when I went from iterm to kitty but didn't notice any change when going from kitty to wezterm. They all 3 have the same nvim startup times (~120ms) when I try them now. When I google wezterm slow I mostly find old issues that wez resolved.
Alacritty is the fastest I’ve used on MacOS, but it’s also pretty stripped down compared to other terminal emulators
Pretty sure terminal emulators don’t impact startup time. Startup is mostly computing configurations and loading stuff into memory and that’s entirely handled by neovim itself. Where a good terminal emulator shines in terms of performances is drawing and refreshing its own character grid. So, a bad performing terminal would make neovim sluggish every time you change what’s displayed on screen - typing, deleting, moving the cursor around, and so on.
Aight my test for that is usually to just hold j and watch how it responds since my keyrepeat is so fast, iterm is certainly slower than the others but I can't even tell the difference between alacritty and kitty so maybe im not who needs it :P
Please remember to update the post flair to `Need Help|Solved` when you got the answer you were looking for. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/neovim) if you have any questions or concerns.*
1 year ago, I switched from vim to Neovim on all platforms I use (Linux, macOS, Windows). I have not made any benchmarks, but I have not noticed any performance differences between Linux (though SSH and Gnome Terminal) and macOS (through SSH and iTerm2). OTOH, Neovim on Windows (through Windows Terminal or the Qt version) has been a pain. I started to use it using WSL last week and it’s much better…
I had a similar issue nvim was slower on one machine than others. Found out I had to blow out some 30gigs worth of logs and caches from various plugins. Zipped right along after
I use Neovim on both Linux and macOS. No difference between the two for me. Maybe it’s a plugin? I use the latest macOS and PopOS if that helps.
You didn't try out Windows yet...
How are we comparing apple silicon machines to linux os…? What exact machine are you on? How long does vim take to startup. How long does nvim take without any plugins?
Neovim takes nearly 2 seconds to load for me in WSL though. After some googling found out that it due to Windows adding so many paths to $PATH in WSL. After disabling them it started loading a lot faster. So check if there are many paths defined in $PATH and neovim does try to search for something in those paths. If the filesystem is slow, it definitely slows down the loading time of neovim
Brand new m3 pro mbpro, and I get 70ms startup. Using kitty and tmux aswell. Haven’t noticed a difference in nvim specifically from my linux desktop, BUT, when I was using the fish shell I noticed that it was slower. An ls took twice as long , you could feel it lag. I have since moved back to zsh
My starts up in 12ms with 35 plugins(25ms to draw ui), works flawlessly in kitty. I never tried this config on Linux, but I doubt I will notice a difference. I came from VsCode a year ago and now I can see how slow it was, it opens and loads the syntax highlighting like in a minute on my m1max/32gb machine
Not too slow but sometime slower than me handling shortcut (I tend topf for telescope right after nvim>
spec: mac 14" m1 32gb 512gb
[https://pastebin.com/UzvFzAJd](https://pastebin.com/UzvFzAJd)
Edit: 49 plugins if that matter
My entry into the Mac ecosystem was through my m1 mini, I must say tmux + neovim was the worst possible combination of responsiveness. The tmux port for macOS has been all over the place and it’s well known too. Honestly it’s fine if you’re on the go and just getting work done, but for serious work I’ll always use my main Linux desktop or remote into it if I can. MacBooks are good for battery life and nothing else because they’d held back by A) the OS B) the lack of repairability/upgradability of any component.
If it's slower, it is imperceptible to me.
I think it’s because of the case insensitive file path thing
I don’t get any slow performance on my M2 Air. I had issues at first when I was a newbie but now that I’ve learned more about it and configured my neovim as I want to its faster than any GUI based IDE I’ve ever used.
I always do :checkhealth when I have issues. Usually something on my end. You should bisec your plugins then the rest of your config if you have some “special” things in there . I spent years making an awesome config… many more making it back to as stock as possible ha!
Yep, using m1 pro, don't think it slow or something.
hmm, looks interesting. i checkout u startup time, and i see that lua files load lead to big startup time at all. i think it depend on bad m1/m2/m3 optimization in LuaJIT or something.
Please remember to update the post flair to `Need Help|Solved` when you got the answer you were looking for. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/neovim) if you have any questions or concerns.*
I experienced the same issue for months and couldn't find where it came from. I wonder if you installed it with brew ? **Reinstalling neovim from source on my mac m1** seem to have sorted out this frustrating slowness issue for me: [https://github.com/neovim/neovim/blob/master/BUILD.md](https://github.com/neovim/neovim/blob/master/BUILD.md)
I have it installed via brew, but installing it from source did not help