Can anyone stick a date when VS became a piece of memory crunching s**t?
-
By which you mean "the days when VS would crash with an out-of-memory error"? :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I can't remember that happening so much that to became so annoying as the current situation... Now the computer as whole is stranded...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
To tame resource hungry apps you can use Process Lasso: Bitsum. Real-time CPU Optimization and Automation[^]
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
They do that on purpose. The point is to preload pretty much everything, and then the .NET GC likes to aggressively allocate gigs at a time ahead of time for its heap. The upshot is the more RAM you pig out on, the better the performance you can get from an otherwise monstrous application. It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Agreed. For me, Chrome and VS consume all my PC/laptop's memory, for sure. Not exactly sure why, but it does appear to get worse with newer versions and as time goes by.
Preloading, caching, and garbage collectors. All of which contribute to vary aggressive allocations. The upshot is better performance. Think of it this way - even when your RAM isn't being used, it's still drawing the same power regardless, but it's not doing any useful work. This way, applications put the RAM to good use - application acceleration essentially - rather than it just sitting idle.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
To tame resource hungry apps you can use Process Lasso: Bitsum. Real-time CPU Optimization and Automation[^]
That's an essential application for older apps on modern PCs. You can do things like run cranky old games (I'm looking at you, Saints Row franchise) on processors with eleventy billion cores by only giving the game two so as not to confuse it, for example.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
They do that on purpose. The point is to preload pretty much everything, and then the .NET GC likes to aggressively allocate gigs at a time ahead of time for its heap. The upshot is the more RAM you pig out on, the better the performance you can get from an otherwise monstrous application. It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
All of this sounds reasonable but what about swap? If VS is consuming more than it truly needs and Word is running without enough memory then parts of VS get swapped out, heading back to VS does another swap, disk is slow even ssd. So I agree with everything so far if all I'm doing is VS. That's never the case for me. I'm probably out of the loop on most of this stuff so take this with a grain of salt. :-D
Jack of all trades, master of none, though often times better than master of one.
-
They do that on purpose. The point is to preload pretty much everything, and then the .NET GC likes to aggressively allocate gigs at a time ahead of time for its heap. The upshot is the more RAM you pig out on, the better the performance you can get from an otherwise monstrous application. It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
The problem it takes gigabytes of memory for no any reason... The combined size of all the binary files, the source, the resources is less then 100th of the memory VS takes... It also force anything else paging intensively... I would except from a good application taking only the memory it really needs...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
So the Performance tab of Task Manager shows 100% of the memory is in use?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
So the Performance tab of Task Manager shows 100% of the memory is in use?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
97% - of which ~70% is for VS 2022...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
The problem it takes gigabytes of memory for no any reason... The combined size of all the binary files, the source, the resources is less then 100th of the memory VS takes... It also force anything else paging intensively... I would except from a good application taking only the memory it really needs...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
Kornfeld Eliyahu Peter wrote:
The combined size of all the binary files, the source, the resources is less then 100th of the memory VS takes
Perhaps you are over simplifying with that statement? Allocation is not the same as use. If it allocates 100 gig but only uses 10 then the 10 is the only thing that can impact the performance. It doesn't swap a 100 gig chunk. Swapping is handled at a much smaller size. So it breaks the total into pieces. And it only swaps what is actually being used (writing/reading) and when it is not already in memory. But also keep in mind that your code and libraries is not all that it loads. There use to be a tool that allowed one to actually track everything that an application loaded. Use to be under 'sysinternals' (many tools) although that was subsumed by Microsoft at some point.
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
Kornfeld Eliyahu Peter wrote:
VS 2022 will use all of it...
That doesn't happen for me. I see it use a lot when it starts up. But it goes down substantially once everything is loaded. The computer has 32 gig. I only have one addin tool loaded which is Resharper. I don't use source control from in VS so that is turned off. I did not turn anything else off (presuming that is even possible.) I am using the Professional version. I also know that Resharper itself can chew up quite a bit of memory when it gets confused.
-
They do that on purpose. The point is to preload pretty much everything, and then the .NET GC likes to aggressively allocate gigs at a time ahead of time for its heap. The upshot is the more RAM you pig out on, the better the performance you can get from an otherwise monstrous application. It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
I've been running versions of VS in VMs for more than a decade, and I've seen the evolution. Newer versions *do* take more and more memory, these days, I have to give my VS2022 VM 20GB of RAM; any less and things start to get glacially slow. I'd like to give it more, but the host (with 64GB) has everything else allocated to other VMs (none of which are given nearly as much as the dev VM). I'm looking at devenv.exe, and right now it's using 2.8GB all by itself. I often see it going well over 3GB. There's a crapton of other associated processes; I'm looking at ServiceHub.RoslynCodeAnalysisService.exe (another full GB) and ServiceHub.IntellicodeModelService.exe, another half GB. Yesterday I had something like "Microsoft.net.exe" (I forget the exact name) chewing up another full GB. I understand that caching is a good thing, otherwise it's wasted memory. But it acts like it owns the neighborhood.
-
honey the codewitch wrote:
It's not fair to say it requires all that RAM. If you gave it less inside say, a VM, it would still run fine, just not be quite as snappy.
I've been running versions of VS in VMs for more than a decade, and I've seen the evolution. Newer versions *do* take more and more memory, these days, I have to give my VS2022 VM 20GB of RAM; any less and things start to get glacially slow. I'd like to give it more, but the host (with 64GB) has everything else allocated to other VMs (none of which are given nearly as much as the dev VM). I'm looking at devenv.exe, and right now it's using 2.8GB all by itself. I often see it going well over 3GB. There's a crapton of other associated processes; I'm looking at ServiceHub.RoslynCodeAnalysisService.exe (another full GB) and ServiceHub.IntellicodeModelService.exe, another half GB. Yesterday I had something like "Microsoft.net.exe" (I forget the exact name) chewing up another full GB. I understand that caching is a good thing, otherwise it's wasted memory. But it acts like it owns the neighborhood.
It may have gotten excessive. I don't notice on my machine, but then this is top shelf dev system, so it eats anything I throw at it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It may have gotten excessive. I don't notice on my machine, but then this is top shelf dev system, so it eats anything I throw at it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I *love* using VMs, but I have to start wondering if there might not come a time where my *development* machine might need to become a dedicated physical box once more. I've been thoroughly spoiled by the idea of doing a full backup of a machine just by copying over a VHD/VHDX file...
-
I *love* using VMs, but I have to start wondering if there might not come a time where my *development* machine might need to become a dedicated physical box once more. I've been thoroughly spoiled by the idea of doing a full backup of a machine just by copying over a VHD/VHDX file...
I have a dedicated machine for it because some of my tools don't work in VMs I use VMs when my dev toolchain can't set up its own virtual environment and needs things like path modifications and such. I don't bother running a VM to run VStudio. I backup all my work on github for better or worse (my clients are aware of this) and that includes ancillary work product like notes and documentation, even media - they go under my project folder in a "notes" folder. Even if I was the type of person that could count on myself to run a backup reliably, I still don't like how heavy handed they are. I don't need that huge autogenerated .vs folder for example. I don't need my massive .git folder backed up either.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
That's an essential application for older apps on modern PCs. You can do things like run cranky old games (I'm looking at you, Saints Row franchise) on processors with eleventy billion cores by only giving the game two so as not to confuse it, for example.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Cool Recoil [^] here we go :jig:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
Don't know if anyone else has posted this, but going 64 bit didn't help. I shut it down and restart it occasionally - that seems to help.
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
Quote:
No matter how much memory I threw at my computer VS 2022 will use all of it...
Depends. I was recently surprised to find VS performing snappier, using much fewer resources and generally doing things faster than VSCode on the same machine and same project. The reason? A project in plain C, with no added dependencies. Turns out, trying to decipher C++/C#/Java/etc while you type is an *expensive* process. The time taken just to reload the (template-heavy) headers for a small C++ 1000-line sourcefile is larger, on my machine, than compiling and then linking a single 4000 line C file into a single executable. And since VS has extensive capabilities WRT to C++/C#/Java source code, all that takes up extensive CPU power, while even the most extensive analysis on C is still a very quick process due to how simple the language is.
-
No matter how much memory I threw at my computer VS 2022 will use all of it...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
Day -365 when the first release candidate came out. If it makes you feel any better (and why should it) ALL programming IDE's are memory hogs. Right now I am running an instance of VS, VS Code, Android Studio and PHP Storm (I have lots of RAM) and the one chewing up the most RAM is Android Studio, followed by VS, VS Code, and then PHP Storm. If you want to know why, write an addin for Visual Studio and get a look at the API. After that it will still suck up tons of RAM, but you will understand why. The only thing that seems to be as RAM hungry as IDE's are web browsers - ALL of them. But then if the have ever worked with the internal gubbins of Web browsers you will also know why.
-
Preloading, caching, and garbage collectors. All of which contribute to vary aggressive allocations. The upshot is better performance. Think of it this way - even when your RAM isn't being used, it's still drawing the same power regardless, but it's not doing any useful work. This way, applications put the RAM to good use - application acceleration essentially - rather than it just sitting idle.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
