Hi, Thank you for a great product! We just placed a preorder for 5 licenses for our development team. But it can get better. I am running Visual Studio .NET 2003 in Parallels VM, on Windows XP SP2 (fully updated) with Parallels extensions installed (beta 6). I am using a MacBook Pro with 1GB RAM, and have allocated >700Mb for the parallels VM. (I will get 2gb of RAM soon enough). Once VS.NET is started, XP reports more than 400Mb available RAM. Visual Studio also have the Whole Tomato Visual Assist add-in installed. Starting the development environment takes up to 2 minutes, and I can't find any reason at all for this. Opening a quite large project that resides on the virtual drive is fast, as is compiling in this scenario. Normal startuptime for VS.NET with Visual Assist installed is less than 10 seconds. However, opening the same project from a mounted folder on OSX (host-only networking) takes even longer - and compiling is 5 - sometimes 10 - times slower. This is a major issue for us, since we want to be working with the same files in several simultaneous environments (SuSE Linux, Windows and OSX). The networking performance is not up for this. So, that's two issues that I think is clearly Parallels related - VS.NET startup time (has never experienced that before, not in Virtual PC on PowerMac or Windows, or on barebone machine), and bad performance of networking to the local Mac. Any ideas? ::Ludvig A. Norin HansaWorld Development http://www.hansaworld.com
I'm using Visual Studio .Net 2003 as well, but I'm not experiencing the startup issue you are having. I don't use Visual Assist (although I might be after looking at what it does), have you tried disabling that to see if you get the same results? I'm having other issues, which I think might be related to either the registry and/or COM problems. For instance, I get an error when using Perforce within Visual Studio and another application cannot access an Access database residing on the same computer.
I stopped using VisualAssist years ago, because it completely sucked out what was remaining of my 1.8 GHz P4 at the time. Our company has switched over to VS 2005 recently, and it works great on my MBP under Parallels. I tried working with remotely mounted source files years ago, but it was never a good situation. Perhaps there is a way to change the default behaviour, but I found that Microsoft just put too many important intermediate files into the code tree. Are you currently working in an environment where you share one source tree across platforms, or is this a new direction for you? I would think it would be much more difficult than keeping separate code trees, as experience tells me that it can sometimes take days (or longer) to work out platform-specific issues, and sharing a code tree would force those delays onto all platforms.
Visual studio disk access and performance I am working with VS 2005 and startup time is about 10 seconds (the same as on my previous Dell machine). Compiling a moderately large project is also very fast. This is on my MBP with 2Gb RAM and 614 MB for the VM. I am running Windows Server 2003 in the VM. From what I remember, VS 2003 (and 2005?) create a lot of temporary files during compilation. This creates a lot of disk activity which may be the the cause of your performance issues. Are you running any OS X application which tries to access the disk a lot at the same time?
I don't have VisualAssist installed and it is talking also little too long comparing to my "real XP" installation. Not sure what it is. I also reported about cursor problem when I set my text editor background to black color. I have 17" 2Gb RAM 2.15Ghz
Personally, I suspect that the reduced disk performance that tends to come with a virtualized environment might be an issue here. Development software tends to thump on the disk a lot, importing headers, writing intermediate files, etc, so you feel the impact of a slow disk a lot more than you do in most other apps. Just a theory.
Hey guys---I too have noticed the dramatic speed difference between native file access (even on an expandable virtual disk) and a file shared over the host-only network. While I have high hopes that Parallels will be able to optimize the performance of these shared files, I have a feeling that we're still going to be stuck with a 2-3x mutliple simply because of the added, unnecessary overhead caused by the host-only network, TCP/IP stack, SMB, etc. etc. Maybe the Parallels shared folders method has less of that overhead. I hope so! But not it is too unstable for me to even try. I recommended a program on another thread that some of you might consider: MirrorFolder (Google for it). This Windows program will automatically sync files between a native Windows disk and any other disk, including a network share. Mirroring can be done in real-time, RAID style (though this might bring the performance down to the slowest store) or on a periodic basis, or on startup/shutdown. This might give you the advantage of more native performance while giving you the ability to access files on the network.
Glad you like it! MirrorFolder is working great for me. By the way, I did a test, and Parallels Shared Folders are actually no faster, and perhaps a bit slower, than SMB shares on the new release candidate of Parallels. Go figure! That's a bit disappointing. I guess if the only advantage is the extra layer of security PSFs provide over SMBs, I can deal with it. I'd sure like to see them faster though.
Good to hear about VS.NET 2005! I have not yet installed it in the VM - I am awaiting better USB support for that - but I will really have to, since it's the only development enviroment we have that integrates all Windows builds including Windows Mobile 5 and Pocket PC 2003 (all our target platforms share the same sourcetree). About VS Assist, it sure slows down VS a bit, but not too much on a decently new Wintel laptop. I was using a Toshiba M205 Tablet PC with 2gb memory as the main development machine before, now I am switching to MacBook Pro (thanks to Parallels). I've had no performance issues with VS Assist before (long time user since 1999). This is easily addressed in VS.NET 2003 by changing a few settings and paths in the project preferences - look for "Intermediate files", the PDB file and the BSC file settings. If you put those locally you will not experience a major slowdown on a regular network, but you will in Parallels VM (which really is doing loopback networking to on the machine - we don't keep sources on a mountable network share). This is not a new direction for us. We support Windows, Mac, PocketPC/WM5, Linux, Solaris, AIX and more, through one source tree. It is not at all difficult, at least not for us. We usually don't spend days on platform specific bugs. The code is quite stable and well designed to work (and be worked on) in this manner. The new direction comes with the great performance of Paralleled Windows and Linux on the MacBook, which enables us to make changes on, say, the Mac (using XCode), and switch to the Windows instance and compile in VS.NET (1 file - the only one that changed), and then switch to the Linux instance (yes, I use that too) and recompile (in Eclipse) that one file. Changing things and test them quickly like this takes minutes, regardless of wether I'm at the office, on the road or at home. This is really, really good stuff - that is why I'd like to see the performance improve for bridged and host-only networking. There are of course other ways of achieving this - but with three full-blown development environments running concurrently (and Virtue, of course), with more-than decent debuggers and other tools, it's not all that easy ::Ludvig A. Norin HansaWorld Development Sweden
Thanks for answering, the startuptime without Visual Assist is significantly faster - I am sure VA is the cause of the startup time issue - but running without is really not an option for me. However, this is not a critical problem for me - I have VS.NET running at all times, and hibernates the Windows instance when I don't need it anyway. But it would be nice to see it solved. It is a somewhat odd issue - VS.NET stalls for up to 2 minutes, using no CPU (almost), and very little additional RAM. It happends regardless of wether I have opened a solution file or not. Regarding the temporary files, see my reply to deebert above. Running a compile when all files reside on the virtual hdd is fast (really), but doing it over the bridged/host-only networking to a local MacOSX share is really slow (20x slower), and doing it using shared folders in the RC1 is even slower (30x), which surprised me somewhat. Ludvig A. Norin ::HansaWorld Development Sweden
Ludvig, As far as I know VA is using pretty aggressive software protection (Armadillo), which has its impact on startup time. We'll look at the issue but no promises here. Regarding compilation over SMB... Have you tried compiling your project on a physical windows machine over SMB on a physical network? Is it any faster than in your VM?
Hi, thanks for the reply, startuptime is not a major issue for me, just slightly annoying - I can live without that. Regarding SMB, no I haven't. I am not using SMB over a physical network - I am using it in host-only networking to access the local folder in MacOS. Up until RC1 I couldn't use shared folders for this (lots of BSODs), but now I can - and it is slower than the SMB solution. Configuring VS.NET to put all temporary files on the virtual HDD (instead of the default, which is the build directory, ie. the smb share) makes it faster, but not nearly as fast as running everything on the virtual hdd. If I did setup a solution to compile off a network share (physical) I would think it would be pretty fast on a 100mbit network, with a windows server and client. It would probably be slower with a MacOS (and SMB) server/windows client, though. Keep up the good work! ::Ludvig A. Norin HansaWorld Development Sweden
I have a question here in respect of memory usage. I use VS2003 on XP VM with 512Mb or 1024Mb Ram set. Looking in Task Manager (XP) I see very little memory in use comparing to running it on native XP on another PC. When running in VM with VS I see about 200-250Mb usage and running the same project on another PC takes about 500-550Mb. Why is that. Is this a display issue. It seems to me that assigning 512 or 1024 Mb to VM does not really make a difference. This is in B6 and RC.
This is what I was actually asking for. Your expectations of SMB performance may be a little too optimistic. If we get some numbers to compare we can decide whether or not this is an issues with Parallels.
No Parallels issue IMHO - SMB performance for compiling is generally low Same here. I moved my development over from an XP box into Parallels on my MBP17". The first idea was to have my former D: data partition as a SMB network drive D: located in the Mac OS X host file system. Then I found performance was dramatically slow. First I thought it was the virtualized setup, but then I did a few tests with compiling on networked drives on native XP boxes and realized how much slower in general compiling on a networked drive is than on a local drive. Of course I know that there is quite some overhead and limited bandwidth for network drives, but I wasn't aware it makes that much of a difference for compiling. After all, compiling is mostly CPU intensive, and disk data involved in compiling even a large project is not really a large amount of data in today's terms. But I guess now that the lack of block level disk caching for network drives makes the big difference (repeatedly reading the same bunch of header files for every source file in a project profits a lot from disk caching). Bottom line: I'm now using a CVS checkout of my sources on an imaged partition to compile, and speed is up to what I expected...
Has there been any more discussion on this? I'm about to get a Core Duo Mac Mini with 2 gigs of ram as my primary development machine and will also be using Parallels as the intermediary between OSX and VS 2005. I fear that since the Mac Mini's have less power than the MPB, that I would see an even greater loss of speed. Anyway, just wanted to see if any of the later versions of Parallels has improved speed for such development applications. Thanks
Using VS2005 I allocated 500MB out of 2GB to Parallels. What made the HUGE difference for me was enabling VT-X. Before that, VS2005 was unusable, and now it's 80-90% native speed. -elan
