1

A bit of background to my question:

I've found it very difficult to search for an exact answer to this question, and an exact answer is the only thing I'm looking for, if that answer exists. I'm on Windows 10. I'm a developer and a power user, I have multiple IDE's open, multiple VMs, about 200+ chrome tabs spread over multiple chrome instances and multiple monitors, etc, and multiple programs running. I don't wish for my workflow to be critiqued, since this is how I enable myself to be maximally productive. If there's other ways, I'm sure we could save that for a philosophical discussion some other time.

With that disclaimer out of the way, I'd like to ask my question, which seems simple but I can't find the answer to it: How do I find out when RAM is a bottleneck to instant "alt-tab" access between open processes?

For example, from my research of windows virtual memory I understand Windows will cache frequently used programs etc. I don't care about this feature since every program I need to use, I want instant access to it (no delay) and thus it is already open.

I notice however that when alt-tabbing between program instances that are already open, especially an open program that I haven't had in-focus for quite some time, there will be a 2-5 second delay in regaining access to that program. That is unacceptable for how I like to operate.

I would like to specify this: Installing additional physical RAM is not a problem for me. That's what I want to do to overcome this, not make any other compromise whatsoever such as running less programs.

The only question I have is how do I quantitatively determine, through the Task Manager or elsewhere, when RAM is a bottleneck to my current usage demands, other than just observing the 2-5 second delay when alt-tabbing between some programs? What metric in the Task Manager, Resource Monitor, or elsewhere can I use to see when Windows has "hit its limit and needs to start caching, compressing, paging" or doing whatever else it has to do to compromise "instant alt-tab snap access" to an already open process?

Looking at memory in Task Manager, it is as follows:

enter image description here

Obviously "Available" is not the correct metric to answer my question, since there is still a slight delay when alt-tabbing between applications that haven't been active a long time (but nevertheless are still open, and haven't been closed since that time).

What metric can I use? Is it the fact that (Compressed) is above 0? Does any compression mean that my RAM is now a bottleneck to instant alt-tabing? Or would compression still take place if it wasn't? Or is it Cached that's the indicator? Or is it Committed?

What is the indicator that adding more RAM would be useful other than the argument "more RAM is always useful"? I'd like to see for myself that RAM is a bottleneck in some way via a metric before deciding to add more RAM. I want to know which metric that is, and also the assurance that adding enough RAM (some eventual amount) for my current open-process demands would eliminate any delay when alt-tabbing, or whether this is unavoidable as it's a design flaw of Windows 10 that can't be avoided no matter how much RAM there is? I'm assuming this isn't the case, but if it is, I'd like to know that too.

Thank you.

  • If you have 13.3 GB available memory then your issue has nothing to do with RAM. – DavidPostill Jun 25 at 7:05
  • from what you are presenting I'd guess that the issue is draw for the processes you are alt-tabbing through, and the Desktop compositor/window manager, rather than global system level attributes like free ram. its clear that even if you added more RAM, your system wouldn't use it. You have more available RAM than many people have in their systems in total. check out docs.microsoft.com/en-us/windows/win32/memory/… – Frank Thomas Jun 25 at 7:07
  • Interesting I see thanks. I just still don't get it though, even keeping the Processor Performance monitor open on a separate screen whilst alt tabbing, there is the odd delay without any of the cores spiking to 100%. I'm having great difficulty identifying the bottleneck. – user4779 Jun 25 at 7:27
  • If your "Committed" memory is anywhere close to or exceeds your actual physical RAM then chances are your system will be paging stuff out to disk or doing other things to try and free up RAM. Compressed memory is a sign that Windows attempted to shrink RAM before paging it out to disk, and having it anywhere above 100MB is a sign that you are hitting memory limits. Sometimes not loading every program you might need is actually the better thing to do. – Mokubai Jun 25 at 8:24
1

The symptoms you describe sound like typical low memory symptoms, but I agree, the numbers you show don't really indicate that. Mind you, you have a commit of 60-70GB, so I definitely wouldn't count it out.

To diagnose the whole thing, I would use process hacker or something similar (process explorer probably has those functions as well, but I haven't used that for a while) to monitor resource use. Set the refresh interval to something short like 0.5s, and let it run in the background. Do your normal work, and when you have to wait 2-5s for the window to switch, set the refresh interval to paused, so you have enough time to check what resources were being used without being rushed. Check for:

  • disk use

  • an increase in the physical ram use

  • CPU usage

  • GPU statistics

You can also the right-click the process you switched to and see the history of its CPU and disk use. If you see a spike in disk use resulting from the process, chances are the process was cached to disk.

You can also try checking your GPU memory, as well as how much (standard) memory the desktop window manager is using. I've had cases where the dwm used 3-4GB, and it's entirely possible the system decided to cache that out.

It might also be worth checking what is using your physical memory, just to be sure it's what you expect it to be.

If you don't recognize anything there, it's possible that your problems stem from limitations of the desktop window manager and/or explorer. I have a similar workflow, and I've noticed that usually the problem isn't the actual memory (I have 32GB as well, but I don't generally need all of it unless I'm running complex calculations in specialized programs), but the windows themselves. I've had cases where it has taken almost half a minute to open the tasks view (or whatever it is you get when you got Windows+Tab - I now use an autohotkey script to move windows between desktops instead). Sometimes I'll also have black boxes in windows or other window rendering artifacts. This has to do with the hardcoded handle limit in Windows, and there doesn't seem to be any interest at Microsoft in fixing this problem. You can increase the per-process handle limit a slight bit, but you can't increase the total limit, unfortunately. There are also a couple of other oddities in this area added in Windows 10 that didn't exist in Windows 7 that I can't quite put my finger on - problems I didn't have with Windows 7 that now happen in Windows 10. Windows just ain't what Windows used to be anymore, unfortunately. Linux is apparently a lot more flexible in this area, although I haven't gotten around to properly try Linux myself.

What I do when I start running into problems is to kill explorer, restart the desktop window manager (in elevated command prompt: taskkill /f /im dwm.exe), then start explorer again. I have explorer set to open file manager windows in a separate process, so I don't lose open windows in explorer, but if you don't have that checked in file options, you'll lose all your open windows. You will also lose your window previews for minimized windows, but essentially, you're clearing that (and any possible memory leaks) to improve performance. You can also restore windows to get the previews back (though you may get back into the situation you just got yourself out of). It's unfortunate that that's necessary - at least in my case - but MS doesn't really seem to care.

Those are the solutions I've found up until now, but it's entirely possible that there are other solutions out there as well.

| improve this answer | |
  • Great answer, thank you. I'm going to give Process Hacker a go. Very interesting you mention the black boxes in windows, also came across that and I assumed it was a memory bottleneck, perhaps loading the pagefile from hard disk to memory, but now that's very interesting it could well be a Windows limitation. I've suspected as much given the vast amount of available memory. – user4779 Jun 25 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.