At this year’s //build/ conference, Microsoft announced the open-sourcing of Roslyn, their .NET compiler for the next version of Visual Studio. Roslyn supports code analysis and code generation for C# and VB.NET languages.
CodeRush customers have enjoyed functionality similar to Roslyn, built-in and shipping since 2005. Although, unlike Roslyn, which currently supports only C# and VB, CodeRush also supports JS, HTML, XAML, CSS and other languages. That functional similarity between Roslyn and CodeRush is unlikely to be accidental. First, having first-class compiler, language analysis, and code generation available to Visual Studio extensions is a really good idea, and good ideas are bound to be validated and improved upon again and again. And second, Dustin Campbell, previously a lead developer for the CodeRush team, has moved on to Microsoft and has been a leading force on the Roslyn team since its inception.
However, in some ways, Roslyn is better than CodeRush’s core engine. One of the things we really like is the snapshot feature, which allows several different plug-ins to safely work asynchronously with read-only images of the code taken at different points in time without blocking the UI thread. And while one of our competitors has openly worried that this will lead to excessive memory consumption, this seems extremely unlikely due to the Visual Studio team’s cleverly efficient design (where snapshots are only a little bigger than the memory required to hold the code changes that have occurred since the snapshot was taken) as well as likely real world scenarios where snapshots are never really needed for a long time, and only exist for as long as they are needed.
The other thing we really like about Roslyn is that Microsoft has finally managed to find performance improvements that beat the same highly-optimized, high speed features we have in CodeRush, such as find all references (which serves as a foundation for many refactorings including Rename). Prior to Roslyn, CodeRush had the fastest .NET find all references (FAR) available, beating Visual Studio’s FAR time as well as all of our competitors year after year. And so we find Microsoft’s performance improvements to be impressive.
Functional and Physical Overlap
Since Visual Studio 2003, any Visual Studio add-in that offered refactoring features also came at a cost, in the form of less-than-ideal performance due to duplication of effort, as well as the additional memory required to hold similar information. Over the years, the CodeRush team made significant advances in the area of both performance and memory optimization. However, we always knew that no matter how hard we tried, there would always be a functionality overlap where CodeRush and Visual Studio were both doing similar work, as well as a physical overlap where CodeRush and Visual Studio were both holding similar structures in memory. And until Roslyn, this overlap was unavoidable.
While moving CodeRush to work more closely with Roslyn offers an interesting potential, it is fraught with challenges. For example, Roslyn only supports C# and VB, while CodeRush’s language-independent source code tree supports many more languages. There are changes required throughout the product. In some cases those changes are minor, and in other cases the changes are significant and may even impact third-party plug-ins.
CodeRush also has over 20,000 test cases, and integrating with Roslyn would likely impact those as well.
We like what the Visual Studio team has done, and we see the Roslyn technology (and its expected derivatives supporting other languages) to be the foundational future of extensible IDE design. And so the CodeRush team is all-in.
We have already started building a version of CodeRush dedicated to totally exploit everything Roslyn has to offer. CodeRush customers can expect noticeable speed improvements for a number of refactorings and core features, as well as see a dramatic reduction in memory usage (e.g. 200MB-400MB less memory consumed for most medium to large projects),
Although this decision is ambitious, the team is taking steps to work as efficiently as possible. For example, we are prioritizing efforts to ensure the most important and the most sophisticated core features get attention first, and we are looking at ways to ensure that every one of our existing test cases remains untouched.
As we get closer to widespread Roslyn adoption, we’ll keep you updated with our progress. By the way, Microsoft recently open-sourced the Roslyn project. To learn more, click here.