6 ms·

At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of

by codeflo 10y ago

At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use. The author acknowledges that this can happen: > So, you’re now out of address space. There are two ways you could try to address this. > a) Think carefully about your data representation and encode it in a more compact fashion > b) Allow the program to just use more memory > I’m the performance guy so of course I’m going to recommend that first option. As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit-fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around. In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.

bicubic 10y ago
Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.
- brynjolf 10y ago
  Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.
  - chillee 10y ago
    It's not slower than VS. It's just not an IDE.
  - lsadam0 10y ago
    I really hope it is. I don't really find VS Code to be any slower than VS. Of course, this depends on what you're using each for. I find I prefer VS Code because it has so few default features. The default install does not contain GB of bloat that I will never need. I'm able to build the experience I want, rather than fight one thrust upon me.
    - ovao 10y ago
      I don't know precisely what the default install size is for Visual Studio 2017, but with the new installer, a Visual Studio install can be svelte relative to previous releases. It's still large relative to VS Code and other editors of course. But the "gigabytes of bloat" problem with Visual Studio isn't so much the case now.
    - jasonkostempski 10y ago
      "I don't really find VS Code to be any slower than VS." Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS. What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.
      - lsadam0 10y ago
        VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".
      - MichaelGG 10y ago
        The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.
- hashhar 10y ago
  The plan that they seem to be following is to convert VS into a completely managed memory product and then move to 64 bit. It's easier and doesn't introduce a feature-freeze period for a project the size of Visual Studio.
  - mtdewcmu 10y ago
    You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.
    - wtetzner 10y ago
      There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".
      - mtdewcmu 10y ago
        Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.
        pjmlp 10y ago
        Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation. Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#. .NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.
        mtdewcmu 10y ago
- daigoba66 10y ago
  Visual Studio Code is a wonderful text editor. But it's far from being a full-featured IDE.
  - ska 10y ago
    Really? I find that really surprising. Because VS itself isn't anywhere close to a wonderful text editor. Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best. Is VS Code someone doing something radically different?
    - tracker1 10y ago
      VS Code started with atom shell (now electron), and a JS based editor that was being worked on for VisualStudio online... combined they were pretty compelling, and at the time so much faster than say Atom or Brackets... It's been my editor of choice since first trying it and only better with each regular release. The entire thing is opensource. Completely open source, rich plugin/extension community. Pretty much has become the editor of choice if you're working on node or go... more than decent with other platforms, and as a general editor. There are extensions to improve workflows, but all optional extensions. I have git history, git lense, eslint, docker, c# (works for .net core), go, jest, npm, npm intellisense, yandex-translate (makes vscode worthwhile by itself), and a couple others. I don't think I can go back... having the treeview, git integration, integrated console, it's all just way awesome to say the least.
    - deleted 10y ago
      [deleted]
deleted 10y ago
[deleted]
mtdewcmu 10y ago
It's a false choice. 64-bit is the future, right? So the 64-bit transition is probably approaching inexorably. Optimizing data structures will be just as good in 64-bit. Actually, it will be even better, because the wasteful data structures will then expend twice as much memory on pointers and become even more wasteful.
ploxiln 10y ago
Since I'm a "performance guy" I use vim ... which has been 64-bit compatible since last century. Sure, Visual Studio is a much much bigger challenge to make compatible. But come on, they've had over a decade during which it was obvious it should be 64bit compatible! A decade! During the same decade-long timeframe they should have been working on lifting the 260 char path limit, another bug they "wontfix". My guess is that they've had really strong product management - they really prioritize those snazzy features and releases, but aren't allowed to spend any time on the technical debt. (And, seriously, they've had a decade ...)
- dosshell 10y ago
  It was fixed in .net 4.6.2 [0] [0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/ https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...
  - Arnavion 10y ago
    It was fixed in Windows :) Any application can add a manifest entry to enable long paths. The .Net change is because .Net needed to expose / add support for it in addition to the base OS supporting it.
  - ploxiln 10y ago
    Wow, fixed in 2016. As I recall, this was marked "wontfix" in 2013: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2156195-fix-260-character-file-name-length-limitation https://visualstudio.uservoice.com/forums/121579-visual-stud... It's been _possible_ using the NT Unicode APIs since Windows 2000: https://msdn.microsoft.com/en-us/library/930f87yf.aspx https://msdn.microsoft.com/en-us/library/930f87yf.aspx But other common first-party windows development tools can still have the problem: https://github.com/Microsoft/msbuild/issues/53 https://github.com/Microsoft/msbuild/issues/53
    - tracker1 10y ago
      I'm half surprised that wasn't in NT4 (prior to 2000 even)... been a major thing that pissed me off in .Net a couple years ago... "why in freaking 2014 is this still a problem?!?!" Was really happy to see it was finally fixed in .Net and the Anniversary update, and long, long overdue.

by codeflo 10y ago

bicubic 10y ago

Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.

brynjolf 10y ago
Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.
- chillee 10y ago
  It's not slower than VS. It's just not an IDE.
- lsadam0 10y ago
  I really hope it is. I don't really find VS Code to be any slower than VS. Of course, this depends on what you're using each for. I find I prefer VS Code because it has so few default features. The default install does not contain GB of bloat that I will never need. I'm able to build the experience I want, rather than fight one thrust upon me.
  - ovao 10y ago
    I don't know precisely what the default install size is for Visual Studio 2017, but with the new installer, a Visual Studio install can be svelte relative to previous releases. It's still large relative to VS Code and other editors of course. But the "gigabytes of bloat" problem with Visual Studio isn't so much the case now.
  - jasonkostempski 10y ago
    "I don't really find VS Code to be any slower than VS." Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS. What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.
    - lsadam0 10y ago
      VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".
    - MichaelGG 10y ago
      The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.
hashhar 10y ago
The plan that they seem to be following is to convert VS into a completely managed memory product and then move to 64 bit. It's easier and doesn't introduce a feature-freeze period for a project the size of Visual Studio.
- mtdewcmu 10y ago
  You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.
  - wtetzner 10y ago
    There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".
    - mtdewcmu 10y ago
      Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.
      - pjmlp 10y ago
        Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation. Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#. .NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.
        mtdewcmu 10y ago
daigoba66 10y ago
Visual Studio Code is a wonderful text editor. But it's far from being a full-featured IDE.
- ska 10y ago
  Really? I find that really surprising. Because VS itself isn't anywhere close to a wonderful text editor. Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best. Is VS Code someone doing something radically different?
  - tracker1 10y ago
    VS Code started with atom shell (now electron), and a JS based editor that was being worked on for VisualStudio online... combined they were pretty compelling, and at the time so much faster than say Atom or Brackets... It's been my editor of choice since first trying it and only better with each regular release. The entire thing is opensource. Completely open source, rich plugin/extension community. Pretty much has become the editor of choice if you're working on node or go... more than decent with other platforms, and as a general editor. There are extensions to improve workflows, but all optional extensions. I have git history, git lense, eslint, docker, c# (works for .net core), go, jest, npm, npm intellisense, yandex-translate (makes vscode worthwhile by itself), and a couple others. I don't think I can go back... having the treeview, git integration, integrated console, it's all just way awesome to say the least.
  - deleted 10y ago
    [deleted]

deleted 10y ago

[deleted]

mtdewcmu 10y ago

It's a false choice. 64-bit is the future, right? So the 64-bit transition is probably approaching inexorably. Optimizing data structures will be just as good in 64-bit. Actually, it will be even better, because the wasteful data structures will then expend twice as much memory on pointers and become even more wasteful.

ploxiln 10y ago

Since I'm a "performance guy" I use vim ... which has been 64-bit compatible since last century. Sure, Visual Studio is a much much bigger challenge to make compatible. But come on, they've had over a decade during which it was obvious it should be 64bit compatible! A decade! During the same decade-long timeframe they should have been working on lifting the 260 char path limit, another bug they "wontfix". My guess is that they've had really strong product management - they really prioritize those snazzy features and releases, but aren't allowed to spend any time on the technical debt. (And, seriously, they've had a decade ...)

dosshell 10y ago
It was fixed in .net 4.6.2 [0] [0] https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/ https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcin...
- Arnavion 10y ago
  It was fixed in Windows :) Any application can add a manifest entry to enable long paths. The .Net change is because .Net needed to expose / add support for it in addition to the base OS supporting it.
- ploxiln 10y ago
  Wow, fixed in 2016. As I recall, this was marked "wontfix" in 2013: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2156195-fix-260-character-file-name-length-limitation https://visualstudio.uservoice.com/forums/121579-visual-stud... It's been _possible_ using the NT Unicode APIs since Windows 2000: https://msdn.microsoft.com/en-us/library/930f87yf.aspx https://msdn.microsoft.com/en-us/library/930f87yf.aspx But other common first-party windows development tools can still have the problem: https://github.com/Microsoft/msbuild/issues/53 https://github.com/Microsoft/msbuild/issues/53
  - tracker1 10y ago
    I'm half surprised that wasn't in NT4 (prior to 2000 even)... been a major thing that pissed me off in .Net a couple years ago... "why in freaking 2014 is this still a problem?!?!" Was really happy to see it was finally fixed in .Net and the Anniversary update, and long, long overdue.