Hacker News Reader

Comment by redblacktree | Hacker News Reader

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.

View on HN

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