A Tale of Two Compilers

re: A Tale of Two Compilers

int19h — Thu, 12 Jun 2008 09:41:41 GMT

> Why two compilers? Well, that wasn't the original plan, but late in the Visual Studio 2005 cycle, the plan changed. The reason that Visual Studio doesn't just use the framework compiler is for performance. Using the in-proc compiler avoids the cost of spinning up another process, and it also reuses a database of interned strings. These issues may not seem significant today, but at one time they had a real performance impact.

This is a good explanation for having a library, but why csc.exe isn't just a console frontend to the same library, then?

re: A Tale of Two Compilers

Weeble — Thu, 12 Jun 2008 11:03:29 GMT

Does the refactoring engine count as a third compiler, then? Or is it one of the two existing ones running in a special mode? I was surprised when I discovered that code can compile normally, but generate compile errors in the refactoring engine. (Already reported through Connect. It was to do with how expressions in arguments to attributes are resolved.)

re: A Tale of Two Compilers

kevinowen — Thu, 12 Jun 2008 18:52:48 GMT

You can also make Visual Studio actually spawn CSC.EXE for builds inside the IDE by setting the UseHostCompilerIfAvailable property in your project (.csproj) file to false (it defaults to true). Just put the following in the first PropertyGroup element at the top of your project file:

<UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>

re: A Tale of Two Compilers

Ed Maurer — Fri, 13 Jun 2008 02:32:20 GMT

int19h, you're right. I only told part of the story. It's true that the compiler guts could easily be a DLL that is linked to by both CSC.EXE and VS, and that was the VS 2005 design. For legal reasons that I won't get into, that was scuttled.

Weeble, the refactoring engine in VS 2008 is a combination of the in-proc compiler run in a special mode to produce some internal data structures along with special purpose VS code to interpret them. The live semantic errors feature that is debuting in VS 2008 SP1 makes use of a path through the in-proc compiler code that is similar to that used by IntelliSense.

re: A Tale of Two Compilers

Stewart Rogers — Tue, 24 Jun 2008 15:24:45 GMT

I have been using VS2008 to build a solution with 36 projects on a high end laptop. The build times have been in the range of 75 sec. the development team started investigating Engineering Workstations with 64 bit quad core XEON processors from Lenovo. We put in RAM Disc for the solution directory and manage our source with TFS. Our first build times using the VS2008 IDE were on the order of 50 sec and the processors performance graph showed approximately 25% utilization across all four processors. After reading this blog and added a .BAT file to automate the build.

"%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe" "..\XXXX.sln" /p:"Platform=Mixed Platforms" /p:Configuration=Debug /t:rebuild /maxcpucount:20

Using the Lenovo Engineering Workstation the automated build took only 10 sec. to complete compared to the identical solution taking 50 sec in VS2008. I would have expected the same performance from the IDE; obviously the IDE’s complier could be improved. I would like to recommend the purchase of the Lenovo workstations but can’t unless the IDE can come close to the same performance as the MSBuild.exe provides. Can you give any guidance on IDE build performance on upcoming releases?