Hacker News Reader

Comment by sosuke | Hacker News Reader

I dunno, I might just be cost prohibitive to port, and likely wouldn't run as well.

Even on a modern, high-powered laptop, Visual Studio still runs slowly for me. Some actions inexplicably cause the UI to hang for a few seconds. I really appreciate how OSX seems to prioritize UI responsiveness, which doesn't seem to be the case in Windows.

I find that a little odd, as my mid-2008 macbook seems to run VS2012 pretty smoothly even through parallels. I have to wonder what else you might be running simultaneously.

Do you have specific examples? This is an area of interest for me. VS architecturally has a lot of things tied to the UI thread due to COM STA requirements (well, that and the fact that historically people created their STA objects on the UI thread, thus tying them to the UI thread).

Another possible cause can be extensions. Not that VS doesn't have its own problems of 'doing too much work on the UI thread', but there are TONS of callback points that third parties can hook into, and lots of times people do very ill-advised things on the UI thread, leading to poor responsiveness.

We monitor it actively (via PerfWatson[0], you should install it if you want your perf problems brought to the attention of Microsoft, it should have low overhead at runtime, only kicking in when the UI thread is already unresponsive), but of course with a product as large and complex as VS, and with said product being extensible, inevitably customers run into stuff we never see internally, so we rely on getting repros/data from them to understand what is going wrong.

[0] http://visualstudiogallery.msdn.microsoft.com/fa85b17d-3df2-...

I don't have a specific example at the moment, except that it's often unresponsive during builds. (I guess this should be expected? Other work I do is in interpreted languages, so there is no "build" step)

Thanks for the link. I'm happy to add it.

Well, I wouldn't say it should be expected during builds. In the past the build architecture was somewhat questionable, i.e. they ran builds synchronously on the UI thread, which works fine if your build takes like 50 ms :) I don't work on the project build team but I believe most languages now build off the UI thread, and any that have long sequences of activities they are doing on the UI thread should still be pumping to prevent UI lockup. That said, running your own pump in an app as complex as VS is...not something to be undertaken lightly, so it is possible their pumps are not correct or their 'in between pump' tasks are taking far longer than they thought/expected. If you can repro it even without repro steps I can give you some instructions on getting a perf trace I could take a look at, they generally point to the culprit pretty clearly.

Which version of VS, and what language? If you're using VS 2010 or earlier, then both C# and VB were running the build (MSBuild and compilers both) on UI thread, so responsiveness was as bad as you'd expect it to be with such architecture. From VS 2012 onwards, VB builds on a background thread, and C# builds out-of-process (which also makes it scale on multi-core systems).

I definitely notice the performance improvements in VS2012. I wonder how many people reporting performance issues are also running ReSharper. JetBrains do great work, but ReSharper (<=v7) is very resource-heavy.

Resharper can definitely bog things down, especially in big Razor pages.

But as you and the parent pointed out, I've also seen huge improvements in build times with VS2012.

And with VS2013 we finally get edit-n-continue on x64.

Reply on news.ycombinator.com