Lagging on Saving

[ownself]

Hello, I have installed Rosly.nvim as my C# LSP Server with default setup, and I'm loving it for obviously better performance than OmniSharp.

And it works perfectly on regular project.

But when I try to apply this to my day job project which is a huge unity game project(Project about 100GB size), every time when I save it it's about 1~2 second time lagging. When I disable Rosly.nvim the problem it's gone.

I wonder if there is anything that I missed about correctly using Roslyn.nvim, any help would be thankful.

Thank you in advance.

[ownself]

OK, I had a little progress, I set filewatching = "off" ("roslyn" will be also lagging), then the issue was gone!

A interesting clue is that the project has this problem is a Unity project which has a huge mount of binary assets(31934 folers and 926814 files). I had another dotnet project has similar scale of source code files with that unity project but works perfectly without any problem.

I'm now guess Roslyn.nvim will be triggered somehow to scan the folders that project has when "filewatching set to auto"?

So I'm wondering is there a way to set the scanning rule or folder exception, or something like that?

[seblyng]

Hmm🤔 Which files are being watched is really up to the server to either tell neovim (in case of using neovims builtin filewatcher), or find out themselves if using the roslyns own filewatcher.

To find out which filewatcher you are really using with "auto", I think you can run :checkhealth roslyn to get a hint after the latest update.

Another thing you can try is to delete one autocmd that is ran on each save with
:lua vim.api.nvim_del_augroup_by_name("roslyn.nvim") to see if that might be the issue.

You can also just edit the source code in plugin/roslyn.lua and delete the BufWritePost autocmd. Just to see if that might be the one that causes the slowdown. However, it seems a little bit weird that it might be that since it seems to remove the lag when turning off filewatching

[ownself]

Thx for the info, when I investigated the issue last weekend, I also tried Claude Code a little bit in Roslyn.nvim, it said something about filewatcher might lead to thousands of handler/callback on saving in my situation, I hadn't gone too far once I'm happy with setting that to 'off'
I'll try your suggestion maybe on this weekend, also might try a little bit deeper this time with Claude Code, I will provide more information once I had some information.

Hope I can help on the plugin :)

[ownself]

Oh, also, with your inspiration, I made a Roslyn LSP plugin for SublimeText myself :)
https://github.com/ownself/LSP-Roslyn
I just started, still rough, please don't make a laugh.

[Rival]

@ownself Mb, I have some clue for you. I also spent some time digging around and setting up my not-a-small project for Unity, and looking to lsp logs I got a ton of this. I am speaking about linux (arch) btw:

[ERROR][2025-10-24 13:38:27] ...lsp/handlers.lua:562    "[project/open] [LanguageServerProjectLoader] Error while loading /home/andrei/Work/Pa│
nda_Unity6_2/SA.Foundation.Tests.Editor.csproj: Exception thrown: System.IO.IOException: The configured user limit (1024) on the number of ino│
tify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.\n   at System.IO.FileSystem│
Watcher.StartRaisingEvents()\n   at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.FileWatching.SimpleFileChangeWatcher.FileChangeContext│
..ctor(ImmutableArray`1 watchedDirectories) in /_/src/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/FileWatching/SimpleFi│
leChangeWatcher.cs:line 57\n   at Microsoft.CodeAnalysis.Workspaces.ProjectSystem.ProjectSystemProject..ctor(ProjectSystemProjectFactory proje│
ctSystemProjectFactory, ProjectSystemHostInfo hostInfo, ProjectId id, String displayName, String language, String assemblyName, CompilationOpt│
ions compilationOptions, String filePath, ParseOptions parseOptions) in /_/src/Workspaces/Core/Portable/Workspace/ProjectSystem/ProjectSystemP│
roject.cs:line 45\n   at Microsoft.CodeAnalysis.Workspaces.ProjectSystem.ProjectSystemProjectFactory.CreateAndAddToWorkspaceAsync(String proje│
ctSystemName, String language, ProjectSystemProjectCreationInfo creationInfo, ProjectSystemHostInfo hostInfo) in /_/src/Workspaces/Core/Portab│
le/Workspace/ProjectSystem/ProjectSystemProjectFactory.cs:line 106\n   at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerPr│
ojectLoader.<>c__DisplayClass19_1.<<ReloadProjectAsync>g__GetOrCreateProjectTargetAsync|0>d.MoveNext() in /_/src/LanguageServer/Microsoft.Code│
Analysis.LanguageServer/HostWorkspace/LanguageServerProjectLoader.cs:line 374\n--- End of stack trace from previous location ---\n   at Micros│
oft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerProjectLoader.ReloadProjectAsync(ProjectToLoad projectToLoad, ToastErrorReporter t│
oastErrorReporter, BuildHostProcessManager buildHostProcessManager, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.Co│
deAnalysis.LanguageServer/HostWorkspace/LanguageServerProjectLoader.cs:line 284"   

so the clue is here:
Exception thrown: System.IO.IOException: The configured user limit (1024) on the number of ino│
tify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.\n at

you can check in with this on your system

Check current limits

cat /proc/sys/fs/inotify/max_user_watches
cat /proc/sys/fs/inotify/max_user_instances

so I guess during the save it starts spamming and throwing exceptions
so setting filewatching = "off" removes the problem

One can also try this

Temporarily increase (until reboot)

sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl fs.inotify.max_user_instances=8192

Make it permanent

echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
echo "fs.inotify.max_user_instances=8192" | sudo tee -a /etc/sysctl.conf

Apply changes

sudo sysctl -p

P.S.
I am not sure about max_user_watches this is AI idea mb setting just max_user_instances will help, I will check later.

P.P.S.
@seblyng you rock! this is a great lsp, it seems it initializes even faster than Rider one, although it is not fair to compare.
The only minor downside in terms of speed, is a nvim lock for 2-4 seconds opening a first file, I guess some initialization may be conerted to async later. Is is a minor issue though.