Move forward and bring back VS UI written in native code
Move forward and bring back VS UI written in native code
Knowing me, knowing you, a-ha
shared this idea
Hi everyone,
I know there has been a lot of discussion on this topic, and the general interest has been around improving the performance of Visual Studio. With VS11 Beta out, we have seen significant improvements in performance.
At this point, we do not have plans to re-write the IDE in native code, and we are going to close out this idea and release your votes for you to apply elsewhere.
We have the performance forum (link is on the bottom of the right hand side of the main VS UserVoice page) where you can vote for specific performance ideas, without using up your 10 votes on the main forum.
thanks,
Doug Turnure (MSFT) – Visual Studio PM
203 comments
-
ashy
commented
WPF is dead. .NET framework is dead. XNA framework is dead. Win32 is dead. Now there are only two windows library, WinRT and DirectX. WinRT is native but can be used with native languages, managed languages o HTML-Javascript. A WinRT-C++ program is faster than a WinRT-C#. So, it's only a time problem, but we will have a WinRt-C++ written Visual Studio.
-
Anonymous
commented
I wish I could vote this down. MS should just make WPF faster (which is good for everyone).
-
ashy
commented
All the advantages of managed are for developers and only indirectly for users (managed memory = minor risks of code bugs). But i am not a developer of Visual Studio, i am an user of it, and then i want use a product written with the best technology for performance, speed in loading files ecc. and this technology is native programming.
-
DeCaf
commented
Seriously? Why would the implementation details of the UI matter? I'd much rather vote for an idea to remove all the native stuff that's left in there (which I guess they're already working on). Surely this would improve stability. If there are things that need improvement, vote to improve these aspects instead. I really don't see how the implementation should matter.
-
Chris Wright
commented
I wish I could vote against this. I didn't even understand what you were actually trying to say until I read the comments... and I disagree entirely, Visual Studio 2010 is by far my favourite IDE and I would love the next version to be very similar.
-
Sergey
commented
Heresy!
-
Andrii commented
Bad idea.
It is too hard to create good UI without markup. -
James L
commented
This is like a user asking you to do the next project in WinForms
-
Philippe
commented
Humm... I'd rather prefer that WPF performance would be improved to the point that Visual Studio and any other applications would run fast so that we could use WPF in our own applications...
-
cpmcgrath
commented
Let's put it simply, whether or not you want this to happen, there is no chance it will ever happen. Don't waste your votes.
-
Grokys
commented
This is a stupid suggestion. The time taken would be better spent on actually improving the performance of VS.
-
chris
commented
I can't believe this suggestion has received so many votes. I assume the vast majority of you are developers and *this* the is the suggestion you vote for? Even the wording is vile, "forward and back." As far as I can tell people seem to be voting for performance. But this just says "I don't like WPF." Anyone who voted for this should be ashamed to call themselves a developer. Certainly *we* are supposed to be impartial and unemotional when it comes to engineering decisions, but here we sound like a know-it-all uninformed shot caller. Boooo!
-
Mauricio Scheffer
commented
It think most people voting for this actually want to vote for this : http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2030253-improve-the-performance-of-visual-studio i.e. they want better performance. But this suggestion is telling Microsoft *how* to achieve better performance, IMHO a mistake. Let them sort it out how. I couldn't care less if VS is written with managed or unmanaged code, as long as it's fast enough.
Also I don't think people writing extensions for VS will be too happy to go back to the previous extensibility model... -
Barry Lapthorn
commented
Agreed with @clively, though it shouldn't be a requirement to update your hardware to get reasonable performance. This item is clearly the same as the second highest voted one which is to improve performance of VS. I see that the VS11 dev preview is already faster to load. The managed code/WPF part of VS clearly allow for much richer visualizers in debug and addons into the IDE. Delay loading parts of VS should surely improve the perceived performance.
-
clively
commented
We've found that simply having a decent video card in your computer radically improves the performance of Visual Studio. Instead of going backwards, I'd suggest that putting a Video Card recommendation on the list of machine requirements is probably the best thing to do.
By way of example, we had Dell machines with video on the motherboard. Loading anything beyond a simple web page in the editor took FOREVER. I then bought regular video cards for all of the developer stations. Once VS fired up, loading those pages in the editor went from 1 minute down to 2 seconds.
-
mrdev
commented
Having the SSD makes the load time acceptable (7200RPM HDD is ridiculous 15 seconds on Core i7 2600K). The problem is while typing it feels like there are little pauses. VS6 editor felt better on a 166Mhz Pentium.
-
Jasper
commented
Please be a rolemodel for others developers by making a fast an responsive app. If you develop amazing tech like Direct2D/DirectWrite/DirectComposition, why not use them? If MS and the Dev Team does not use them - why should others? :-(
-
Qwertie
commented
One more idea that might solve a lot of complaints about .NET performance: support ahead-of-time compilation with static linking, like Mono does, and support interop even better. That way, the native-code people can be convinced to write some of their code in C#, and learn why C# people prefer it so much :)
I kid, I kid. But seriously.
-
Qwertie
commented
P.S. sorry for the WPF hate. It's just that I spent the last couple weeks trying to accomplish something very simple with it.
-
Qwertie
commented
-1 from me.
.NET may still be slower than C++ as my benchmark shows: http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
However, usually if managed code is *noticibly* slower, it's either because the developer is (A) ignoring performance issues (lazy) or (B) using WPF (a very mysterious beast whose performance characteristics are hard to understand and hard to improve.)
MSFT should not return to the land of dangling pointers, badly decorated COM apartments and 60MB PCH files. Instead they should
1. improve the JIT
2. add intrinsics for instructions that might be CPU-accelerated (e.g. 64*64=128bit multiply, rotate, count-leading-zeros, SIMD) and support these operations even on CPUs without special support for them.
3. make an elegent, easy to use, compact, highly flexible UI framework that does not in any way resemble WPF
4. tweak C# to make performant code easier to write ( more ideas at http://loyc-etc.blogspot.com/2010/05/new-features-net-framework-should-have.html )...until C# is every bit as fast as C++.
