I work daily with Visual Studio since 1997 but still use Rider from time to time to keep up with progresses since we plan to also integrate our NDepend extension in it. I use Resharper in Visual Studio for a decade and despite all the great work done by the Visual Studio team I still rely on Resharper for some productivity features (as explained here).
Rider is often deemed as a faster IDE than Visual Studio so I decided to benchmark the two IDEs on some large projects. Here is the context:
- Visual Studio 2022 17.2.4 vs. Rider 2022.1.2
- The machine Xeon(R) E-2176M 2.70GHz with 64,0 GB RAM and 2GB SSD, Windows 10.
- The NDepend solution is made of 38 projects 5.937 source files
- The NopCommerce solution is made of 28 projects 5.325 source files.
Each number was measured several times and here are the best numbers:
| Visual Studio 2022 (17.2.4) with no extension | Visual Studio 2022 (17.2.4) with Resharper extension | Rider 2022.1.2 | |
| A) Startup until Start Window gets responsive | 4s | 6s | 5s |
| B) Startup with our solution: responsive code editor and Solution Explorer | 17s | 20s (first responsive)
25s (fully responsive) |
13s |
| C) Rebuild All our solution (after Clean Solution) | 22.2s | 22.3s | 23.4s |
| D) Startup with NopCommerce solution: responsive code editor and Solution Explorer | 18s | 18s (first responsive)
24s (fully responsive) |
13s |
| E) Rebuild All NopCommerce solution (after Clean Solution) | 49s | 52s | 43.2s |
Visual Studio 2022 brought a lot of performance improvements but Rider is still faster most of the time.
UI responsiveness
The UI responsiveness after startup can be hardly measured. When opening a large solution in B) and D), with Rider once the UI is shown it is fully responsive. With Visual Studio once the Code Editor and the Solution Explorer become responsive to keystroke and mouse click, it still takes “a few seconds” until we reach full responsiveness with zero lag, hence the two measures first responsive and fully responsive.
The awesome Rider responsiveness comes from its architecture: the UI itself (the frontend) based on IntelliJ IDE is rendered in a process while all the .NET backend engine (compiler, analyzer, resharper features…) runs in some separates processes. The frontend and backend communicates through a fast IPC medium (related with Jetbrains Reactive Distributed communication framework for .NET, Kotlin and C++). Despite the fact that Visual Studio 2022 delegates a lot of computation in background processes, it didn’t reach yet this maturity and its UI sometime lags because of some in-process intensive computation. However looking back at the last years evolutions it is clear that delegating as much processing as possible out-of-process is a solid Visual Studio trend. For example in September 2021 the VS team even announced Out-of-Proc Extensibility Model.
Resharper clearly slows down Visual Studio since a good part of it still runs in the frontend devenv.exe Visual Studio process. Several years ago Jetbrains announced resharper out of process but the extension is not yet there and there is no evidence AFAIK that it is actually a high priority project (see latest discussions and improvements on this matter here).
Build Performance
The Rebuild All duration in C) and E) can be measured objectively but it is harder to get numbers for Incremental Build when only modified projects and their dependents are rebuild. My feeling is that Resharper and Rider have a smarter incremental build heuristics (in the sense less projects are recompiled each time) but it really depends on each project detail. Moreover if build performance is a concern for you, there is certainly something that can be done to improve it as explained in this post: Improve Visual Studio Build Performance
Start Window
The Start Window poor performances with both IDE struck me. Reading the Most Recently Used (MRU) projects list and showing the Start Window shouldn’t take more than a second. I know that for a fact since NDepend starts in less than a second (on the same machine) with MRU list, significant UI loaded, licensing check and more.
However it takes 4s to 6s so somehow much more is done before the Start Window gets shown. Whatever is done (reading the list project templates, starting the IDE core stuff, starting the extensions…) it should be postponed asynchronously and possibly out-of-process once the Start Window gets shown.
Search
I didn’t measure the Search everywhere performances because in both cases it is almost instantaneous. Rider search is a tiny bit more responsive but Visual Studio search can be still considered as instantaneous thanks to the recent improvements. However the Rider result list is more dense and complete IMHO.
Btw see below a screenshot of the NDepend search result – which is also instantaneous – which proposes various search criteria (by name advanced, by complexity, by size, by coupling, by change since baseline, by coverage ratio …) and which generates a code query that can be edited to refine the search (search by name + that uses XYZ + that is too complex + that has been modified since the baseline + that is too complex…). It is not meant to replace Search everywhere but to fill the gap for more advanced scenarios – like for example to generate a first draft of a code query to be refined to list code elements that must be moved or refactored for example. Such query result is then a refactoring and/or improvement TODO list.
Conclusion
This post is by no mean a full comparison of the two IDEs but I wanted to put numbers on the performance feeling. Rider is faster, not 4x times faster (like seen in a comment) but noticeably faster like 20% to 50% faster. You’ll find complete comparison of the IDE on the web. To summarize the overall consensus is:
- Rider shines with its performance, the fact that it is multi-platform (unlike Visual Studio for Mac that is not really the original Visual Studio) and has all the Resharper goodies out of the box (refactoring, analysis, unit-testing, some cool debugging features…). It is also well suited for Java developers that switch to .NET.
- Visual Studio has better support for legacy frameworks still massively used (.NET Fx, ASP.NET MVC, Webforms, WPF, Winforms …) and supports more languages (C++, Python…). Also Visual Studio paid editions are more expensive than Rider but Visual Studio proposes a solid enough free version.
Those pro/cons might explain to a large extend that large corps with large legacies might favor Visual Studio while solo-dev and small teams might prefer Rider. Recently a reddit/dotnet post asked what is your preferred IDE for C# .Net development? and Visual Studio got 67% of the poll:
Interestingly enough the vast majority of comments are praising Rider so there’s likely a large portion of silent users here.
Actually both Visual Studio and Rider teams are working relentlessly to prepare the future so it’ll be interesting to see what’s next.