Solving Very Slow Visual Studio Build Times in VMWare
October 31, 2012 6 Comments
In 2009, we chose 15″ MacBook Pro BTO over Dell, HP and Lenovo offerings. Apple offered us the best hardware and equivalent lease terms but with much simpler servicing done by ETF rather than (often incorrect) paper statements and checks. 99% of the time we ran this MacBooks with Windows 7 under Boot Camp. When I started doing some iOS development, I ran Snow Leopard and Xcode under VirtualBox and when I got fed up with the flakiness, I used VMware Workstation.
OS X didn’t run very well under virtualization mostly because accelerated Quartz Extreme drivers don’t exist for VMware Workstation. Still, it actually worked well enough and was much more convenient than dual booting — which is such a huge time suck.
When the lease period ended, we renewed with Apple and decided to just use OS X as the host environment for a variety of reasons:
- Battery life is substantially better with OS X
- Disk I/O for virtualized Windows under OS X is better than under Bootcamp
- We already virtualize some projects in order to replicate a client’s environment
- The UNIX environment in Windows is going away and MacPorts has a huge library of ports that mostly just works
- OS X gets all the cool toys
- I don’t see myself living in Windows 8 on a dual-screen machine
The Slowening
… (Full disclosure: I work on VMware Fusion.)
…
I have heard that storing the code on a “network” drive (either an HGFS share or an NFS/CIFS share on the host, accessed via a virtual ethernet device) is a bad idea. Apparently the build performance is pretty bad in this configuration.
Oh really? Hmmm. Maybe it isn’t that my class libraries are so complex but something else is going on. Here are some empirical measurements of rebuild time of an actual solution:
VMWare shared folder: 50 sec OS X SMB share: 18 sec within virtual disk: 9 sec
Wow. Problem solved. Incremental builds are basically instantaneous and a full rebuild takes 9 seconds when the code is hosted inside the VM image.
Not only does hosting the source code within the VM virtual disk make the build go 5.5x faster, the CPU time of csc.exe goes way down. I don’t know how the VMWare shared folder is implemented. It appears as a mapped drive to a UNC name to Windows but it is very slow.
Moral of the story is just don’t host your source code on the host machine with VMWare. The performance penalty is just not worth it. If you need to share the source code tree inside the VM with the host OS, create a file share from the VM to the host over a host-only adapter.
thanks for sharing. I’m just trying to evaluate the option to have a configuration similar to yours running windows in a vm on a Macbook. Would be good to see how a build on a native windows machine performs compared to the one you do in the vm. got any figures?
On our previous-generation ~2009 dual-core MacBook hardware, I ran Windows for Visual Studio in a native Boot Camp partition and used VMs primarily for browser testing and light iOS development. (Xcode was pretty miserable running on OS X in a VM).
On the new machine, I haven’t bothered with Boot Camp. Windows on the VM with just 2 virtual cores is faster than native was before. The convenience of having different VM configurations for projects/clients trumps even considering dual boot for me. I dot have benchmarks.
FWIW. I do have a 4-core Sandy Bridge i7, SSD and 16GB of RAM. I sometimes give a large Windows Server VM 8GB of RAM. Usually 4GB is adequate. I also tend to split my workflow between Windows and OS X apps. I have a dual-monitor configuration and put the Windows VM full screen on one. Visual Studio does not work well with Unity as there are a lot of weird rendering glitches and the redraw performance is terrible. When just on the laptop, I put the VM in a full screen Space.
sounds like the way to go! the argument of having different vm configurations for different clients/projects is actually one of the most important points for me besides the performance.
thanks again Brian,
cheers
Oliver
There are scenarios where use of VM breaks down.
For example, it may be tough/unsupported (beta) to configure Hyper-V within a VMWare VM. Hyper-V is required by the Windows Phone 8 emulator. I haven’t tried it at all.
I work on a particularly large application. and when i say large, i mean huge. The compile time for people on windows dev boxes is ~20 minutes with a mechanical disk, ~8-13 with an SSD.
With my Macbook Pro with Retina display – Vmware fusion 5 running windows 7, visual studio 2010 – compiling with the code on the mac partition shared with windows, my compile time was ~48 minutes. Moving the code onto the virtual machine cut the compile time of the full application to 5 minutes.
Thanks for sharing! I’ve run in to the exact same thing with gcc. I do all my development in OS X using MacVim, but I need to build for Windows. If I try to compile from the working copy in OS X using VMWare’s Shared Folder feature, it takes AGES. If I copy same code to the Windows virtual disk and compile from there, it’s many times faster. Glad to know I’m not the only one.