NDepending Resharper


Andrew Kazyrevich has written an original blog post about NDepending Resharper. Or more precisely analyzing the code base and API of Resharper  with NDepend and comparing the evolution between Resharper v4.5 and v5.0.

You’ll see some quantitative information include the facts that R# is a 0.5 M Lines of Code application and has grown up by more than 10% between v4.5 and v5.0.

Concerning the very large and complex methods found, I’d like to precise that they are certainly generated. R# being comparable to a smart compiler, I wouldn’t be surprised that a large portion of its code is generated, as for every compiler.


A side-remark. I noticed that R# code base is so big, that just the fact to load the hundred of R# assemblies when starting VisualStudio takes 3 to 4 seconds on my machine. 2 trails to explore:

  • Partitioning the code into less assemblies (as explained in Advices on partitioning code through .NET assemblies) to divide the CLR overhead of loading many assemblies. Indeed, each assembly load needs some security verification, some dedicated file access, some assembly meta-data reading…
  • Making so that R# assemblies are loaded on-demand when the first VS solution is loaded (which of course postpone the slow-down penalty from VS startup time to solution loading time). According to a quick test, 72 R# v4.5 assemblies are loaded at VS startup time (for a total of 84 R# v4.5 assemblies).


Anyway as VS + its eco-system is growing in managed code size, unfortunately, VS startup time is de-facto slower. Only hardware optimization will make it faster. Here is what Rico Mariani (VS PM) said about that in: Visual Studio 2010 Performance Part 1: Startup

(…)We decided to make some investments in better display technology in this release and for the future; that meant loading WPF at startup. We decided to have a superior extensibility model for our future and that meant MEF at startup. And in general we went from having no managed code at all at startup to having a LOT of managed code at startup. That stuff isn’t free, and nobody knows it better than me. [I rhymed]

In some cases I’ve seen as much as 75% of our time in current startup scenarios actually in clr.dll – incredible isn’t it? In VS2008 that was 0%! But even though that’s technically true, it’s also a bit of a lie… (…)


This entry was posted in Lines of Code, LoC, MEF, NDepend, optimization, Partitioning, R#, Resharper. Bookmark the permalink. Follow any comments here with the RSS feed for this post.