I suggest you ...

Move forward and bring back VS UI written in native code

Move forward and bring back VS UI written in native code

3,854 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Knowing me, knowing you, a-ha shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

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

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • ashy commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    I wish I could vote this down. MS should just make WPF faster (which is good for everyone).

  • ashy commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Philippe commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    This is a stupid suggestion. The time taken would be better spent on actually improving the performance of VS.

  • chris commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    -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++.

← Previous 1 3 4 5 10 11

Feedback and Knowledge Base