Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
We continue to drive for improvements – trying to make contact with every person who reports issues (via my blog, Connect, Surveys, etc.). We’re released on “Super-Limited Community Technology Preview” to individuals who have reported problems and are on the brink of releasing another.
Every day we are seeing wins. One of the many issues we’ve been tracking the last few weeks has been that localized/international installs were substantially slower than English (yeah, I know you are thinking that would be hard :)) – on the order of 2 times slower in some cases. Just this morning I got word that a WPF improvement has been tested and we are now nearly at parity with English. There’s also a resource loading fix in the pipe that should erase any remaining issues. It looks like one more problem is down and we’ll keep cranking on the rest.
I thought I’d share a few quotes we received from customers who have tried out the LCTP1 build. I’ve asked for numerical data in addition to anecdotal but the anecdotal also makes a nice read.
We are also making a big push to get all of our internal dogfooders to update to SLCTP 2 and will be following up with a survey once people have had time to get a feel for it. We’ve picked up several key dogfooding teams that we’re working closely with on their experience, including: Expression, Exchange and CodePlex in addition to the Visual Studio teams.
We’re not done but it’s good to see some progress. SLCTP 2 should be better and by the time we get a more broadly available RC out after the first of the year, I’m very optimistic that the problem will be gone and Beta 2 will have proven very successful in helping us make sure we ship a great product.
Brian
The biggest problem i have is that in large class files (i.e. windows forms with tons of code in the file for event stubs etc.) it slows to a crawl if you don't type fast to prevent it from going into whatever background thread it's doing. VS.net 2008 exibits the same problem.
This is all so encouraging to hear!
I generally run multiple instances of VS at once, a mixture of 2008 and 2010, they all have R#, VisualAssist and VisualSVN running (I don't let R# and VA fight over the same files though). I'm on a 32-bit Win7 machine with 4G (i.e. 3.5G) of RAM. I tend to put the machine into standby overnight, so instances are often running for days, sometimes largely backgrounded because I'm working on other things. I don't like endlessly opening and closing VS, because it's so slow to do so, particularly 2008.
If VS2010 becomes painfully slow (as it does sometimes) in this sort of setup, is it worth me reporting this (via Connect), or is a setup like this just too difficult for people to "apportion the blame" when it runs slowly? I don't really want to file Connect reports if the first response is "what's it like if you disable the add-ins and then use it for another 24hrs", even though I would sympathise with the author of such a response.
But neither do I want miss-out on helping you guys get real-world performance data.
Perhaps this is just an obvious case for more instrumentation/telemetry, and I should wait for Devnext for this.
In summary, what's the best way to make reports of the vague: "in my complex world I find VS2010 is a somewhat sluggish application and I know it might not even be VS's fault"?
I definitely think we want to know about it. We have some perf diagnostic tools. I'll ask David Berg to comment on options.
I talked to David, I think the best bet is to use this tool: http://visualstudiogallery.msdn.microsoft.com/en-us/e8649e35-26b1-4e73-b427-c2886a0705f4
to collect logs of the performance issues you are experiencing and send email to devperf at microsoft.com to ask where you can upload the logs for someone to look at.
Thanks,
Brian - thanks for this. I'm downloading the tool now. There's an amusing irony that even the PerformanceDiagnosticSetup.exe is >100MB :-)
Heaven help us all when you let these people loose on a 64-bit version of VS!
What I love about this is the fact that we as developers win from this in 2 ways - obviously VS2010 will be a better product because of it, but also because the underlying framework (WPF et al) will be improved as well.
The fact that you're being so up front about all these issues is also much appreciated - keep it up!
Geminiman, what language are you using? I'd like to get some more information from you on this feedback. Feel free to email me at my microsoft.com address (scottwil). Thanks.
Do you have WOW64 as a test case?
I'm seeing really bad performance under Win2k3x64 that I don't see under Win7x32.
Yes, we do test WOW64. We have another run going right now so I'll see recent results in the near future. The last results I have are for Dec 4th (WOW64 on Vista). They show some things faster and some things slower, but on average, it's about a wash.
There are many things that could contribute to significantly different performance here. Is it the same hardware? Win 7 has SuperFetch (http://www.microsoft.com/windows/windows-vista/features/superfetch.aspx) and Win2K3 does not. That's going to make a big difference on on scenarios and accentuate the effect of a slower hard disk system.
Hi Brian,
Yeah, it's different hardware, although its got a 6 disk RAID5 array so it should be pretty fast.
Anyway, it's not my primary platform, so it's not that big a deal to me. Just wanted to give you another data point.
Brien
I would not recommend running a development environment on a RAID5 configuration. RAID5 is VERY slow. Read performance is fine, but write performance is abysmal. Every write turns into 1 read and 2 writes - making it up to 3 times slower than a single disk. RAID 5 uses a check sum system that requires every write to read the checksum page, recompute the checksum and write the checksum page (in addition to the data itself).
RAID5 is best for applications that require redundancy but where the I/O load is HEAVILY slanted toward reads and has relatively few writes. That's not really a good charactarization of a development environment.
On a single user system, the effect isn't going to be too pronounced because all the I/O is spread across 6 drives (in your case). However, it's nothing like the striping you get in a RAID0 or RAID10 system.
You can read more on the Wikipedia page for RAID5: http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5_performance
Re: RAID5
Isn't compilation mostly disk reads and typically largish writes of binaries?
RAID5 is almost as good as RAID0 for reads and is fast for large writes.
I use it on my primary development machine with VS2003 and it smokes.
You are right that there are a fair number for reads but there are also a lot of writes (temp files, assemblies, pdbs, etc). I don't know how big they are but I'd expect they aren't very big. I'll check with the compiler team.