Apps using large share of RAM on my MacBook running macOS Ventura

You can go stark raving mad looking at the dynamic contents of Activity Monitor and fretting about things you have no control over since the operating system owns or controls most of what you see there. Want to use less RAM? Then quit unused running applications and launch fewer depending on your installed RAM.

RAM is dynamic memory managed by the MacOS. Unused RAM is wasted RAM. Why the concern over RAM usage? RAM will be reallocated by the MacOS dynamically and as needed.

Each app will use the amount of RAM it requires. A few apps will let you set a maximum amount of RAM it will use (one example is Photoshop) ... but most apps don't.

When you start additional apps, other apps do not "reduce" their RAM usage.

When you close an app window the app is still running and will continue to use RAM. You must Quit an app to free up whatever RAM it may be using.

Read the following:

https://www.techtarget.com/searchstorage/definition/virtual-memory

Also the "Real Mem" column says how much RAM the app is currently using.

The "Memory" column is telling how much virtual memory address space the app is using, which maps to the number of virtual memory page tables the operating system is managing, where just a few bytes are used to keep track of 4 or 16 or 64, etc... kilobytes.

Virtual memory address space may map to real memory, it may map to page/swap file storage, or it may be addresses that have not been assigned to anything just yet.

The virtual memory addresses may be used to map application code. It may be used to map shared code libraries. It may be used to map the applications stack. It may be used to map the data used by the applications. It may be address space requested by the application, which the app has not gotten around to assigning a purpose just yet.

Your thoughts on how virtual memory works is way too simple, when in reality it is extremely complex. And I only have half a clue, because back in the mid-1970's I was responsible for writing a virtual memory hardware diagnostic on a very simple 16-bit computer. Virtual memory has evolved tons since those days, and I've been able to follow some of it, but other aspects even go over my head.

repent1 wrote:

But why telegram takes 2-3 gigs and in does not go lower when I open a lot of other apps. I thought it would dynamically change according to pressure of memory...

That's just not the way memory allocation works. You would need to question the developers of Telegram as to why their app may consume so much memory.

repent1 wrote:

Thanks for your answer. I'll check it out

So you meant that the REAL MEMOMY es exactly physical memory? and MEMORY is a virtual memomy?

Yes. “Real Mem” is how much of the app’s code and data are using the physical RAM chips.

And that is even complicated, because code libraries and frameworks can be shared by multiple processes so some of the “Real Mem” reported, my be shared with several dozen other processes.

“Memory” is reporting virtual memory address space. Virtual memory is like the Alice in Wonderland Cheshire Cat. Sometimes it is in RAM, and sometimes it is not. And sometimes only parts of it is in RAM. The Cheshire Cat was the Digital Equipment Corporation’s VAX/VMS operating system mascot.

As to the window server, its virtual memory footprint is going to grow based on the peak number windows you have displayed, as well as windows an app may be building, but has not displayed just yet. And windows can be, menu bar menus, pop-up menus, dialog boxes, notifications, etc…

Code and data can be on disk (SSD, NVMe).

As code is executed, Virtual memory will page-in the application code from the executable file, and it will page-in code from the shared library executable files, on demand. If code is not executed, it is not paged-in to RAM. If code has not been executed recently, and there is memory pressure from other demands on RAM, the RAM being used by the app’s idle code is freed, and the virtual memory page tables entries associated with that RAM change to point to the executable file, so the code can be paged back in if it is needed again.

Modified data in RAM, can be paged-out to a page/swap file on disk. This also happens when there is memory pressure and the chosen data pages have not been used recently. Again the virtual memory page tables are updated so they point to the location on disk where the data has been stored, so that if the app wants to use that data again, the operating system knows where to read it on disk and bring it back into RAM.

It is like having a small work space, but a storage room, you can move thing you have to work on between your work space and the storage area. You may have work space room for several things, but eventually you have to move things back to storage to make room for other things you need to work on.