Visual Studio 2010 RC on vm ws 7.0, win7 x64 very slow

[BillInPA]

I installed visual studio 2010 on a vm workstation 7.0

Base machine is dell precision, win7 x64, 8 gigs ram, very fast box

Gave the vm 1.5 gigs, 2 cores

When building, the ram is around 50%, and cpus are around 50% in task manager/performance

Building a c++ solution with 2 projects, each around 250 .cpp files, takes almost 30 minutes

A vmware XP SP3, vs 2003, same solution, takes around 2 or 3 minutes for a full build

the 2010 takes 20 minutes

looking on visual studio 2010 blogs/etc, everyone is excited about the performance

im feeling a little left out of the party...

I am not a vmware expert - this is my first vmware machine

anyone have any ideas/tips?

[Scissor]

Try changing your Guest to 1 vCPU.

Do you have any CPU intensive tasks running on your Host? Are you running more than one Guest at a time?

[BillInPA]

Thanks for the reply

I originally had it at 1 cpu, changed it to 2 because I hoped that would help

At your suggestion, I put it back to 1, and its no better.

The host is basically idle, no other vm sessions running, so basically that one image has the entire machine

I had my source and build target on a mapped drive into the vm-host

Copied it all into the vm images c: drive, that helped some, but not enough that I would say this is ready to use as a production environment.

Since the whole reason for vmware is to have multiple operating systems, its not practical to duplicate the source in multiple images.

I think next I will try an external drive, which I can mount as a direct device in an image

That way win7 wont see it as a network folder, which raises heck with the win7 filesystem redirection

Between the host being win7 x64, the image being win7 x64, vmware, and vs2010, its have a lot of new technology to coordinate.

I would likely have better performance if sv 2010 were on the base image, but its the release candidate, not the releasse version, so I dont want to muddy up my base machine with something that I will be uninstalling next month or so.

[Scissor]

Please attach the vmware.log and .vmx files from the directory containing your Guest and I'll take a look.

[BillInPA]

Thanks for the reply

I zipped them up, however I think I have found some useful things

I moved the source and taget folders from the z: drive, which was shared by the host, to the guest's c: drive

I suspect windows 7 filesystem redirection gets triggered when you run from a network drive, so debugging wouldnt work

Also, turns out unless you get the vs2010 project files just right, it does a total rebuild every time

In the project general properties are options TargetDir, TargetName, TargetExt

They have to be set for the final output of a praticular build configuration, for example the Debug or Release configurations

Then most important, the linker/debug/pdb file has to be $(TargetPath).pdb or $(TargetDir)(TargetName).pdb

Unless it is set as such, it seems to trigger a rebuild all, even if nothing has changed since the last build

Lastly, it seems that after a conversion of a project file from 2003 to 2010 - thats the only conversion i did, so i cant speak for 2005/2008 conversions - you have to go in and carefully check the Precompiled Headers settings

I found that between getting the .pdb and PrecompiledHeaders the way they should be, a rebuild is comperable to 2003

Our projects had gotten a little sloppy over the years, having survived several code splits, so that I think was where the trouble started

The Windows 7 filesystem redirection gave me fits, I finally had to disable UAC to get the debugger to let me in

[mdunn-vmware]

I know that beta builds of VS 2010 had some bad performance problems when running in a VM, due to how they were using WPF. There is a registry entry you can set to change the behavior of WPF to work around this slowness. I'm not having any luck finding info on it at the moment, but I know I've heard it mentioned in a Channel 9 interview about VS10.

[BillInPA]

What I eventually found is, when setting up VS projects one must do all output specification in the Configuration Properties section (for c++)

In there, the Output Directory, Intermediate Directory, Target Name, Target Ext should be set as needed

Any paths - like Output Directory - should end with a backslash like "C:\myTest\"

Then, in subsequent areas like Linker/Output File, use $(OutDir)$(TargetName)$(TargetExt)

This is the setup vs2010 likes - if you override output paths or names in the compiler, linker, or librarian areas it can cause slowdown plus some instability in vs itself. But, once we had our projects all set up this way, it behaves pretty well.