macOS Monterey 12.6.5 and Big Sur 11.7.6

Mhh…well…my problems are rather the other above mentioned programs which before updating did not consume as much ram!

I understood that, but since the new Memory Management was introduced by macOS Mavericks, RAM usage monitoring became a thing of the past. Whether 12.6.5 caused those programs to appear to be using more or not something for you to stress over. The OS is managing things just fine.

1 Like

I agree with Al Varnell’s advice. If you are not noticing a change in the actual performance of the machine, it probably is not worth worrying about the memory usage. For better or worse, current operating systems take a much more active role in memory management than they used to, while limiting the practical steps that users can take to manage memory. My guess is that the OS is caching data more aggressively than in the past and that the cache will be purged as needed by the OS when you need more RAM.

I realize that may not be a very satisfactory answer. Modern operating systems seem much less productively “tweakable” than their predecessors.

1 Like

I can’t work because programs refuse to work - lacking RAM. So it’s, as I wrote, severe!

Hello @Bremen-Sebastian - Thank you for the additional information. It makes it easier to try to help. It is very common for people to worry about increased RAM usage in later versions without actually having a problem using their machines. Obviously, if you are having problems getting programs to work, you have a different situation.

Does the problem happen immediately after rebooting your Mac? There were reports on earlier versions of Monterey about “memory leaks,” where the amount of memory taken by apps increases during use until serious performance issues occur. Perhaps that is still happening.

There also is the possibility that the problem is not related to RAM. As Al Varnell suggested, the “speicherdruck” graph in the screenshot you shared does not appear unusual. How does your CPU activity look when you have this problem?

Sometimes problems with a drive can substantially interfere with applications. You might try rebooting into the startup utilities and running the Disk Utility First Aid procedure.

Yes, do not be overly concerned about RAM usage if it there is no degradation in performance. Perhaps the attempted summary on memory usage I posted in an earlier thread (and the discussion) is helpful.

1 Like

Please tell us how you know this. Are you receiving a notification that a program cannot be launched due to a lack of Application RAM? That would change this discussion completely.

1 Like

Hi folks, thanks and I’ll do, it’s just, that I probably can’t do it before Monday! I come back to your help!

Yes, up to a point.

Do not concern yourself with the amount of “free” memory. Trying to maximize free memory is actually counterproductive, because that’s memory sitting idle, that could be put to better use.

Modern operating systems (including macOS) will use otherwise-free memory to cache various things, like system frameworks, shared libraries and recently-used data from the file system. If the OS would actually free this memory, it would have to reload it from storage later on, hurting performance. If apps need the memory later on, the system can quickly discard it at that time.

The thing to look out for is if your system starts swapping. There may be a small amount of swap used - this is not a problem. But if it grows to a significant percentage of your total memory size during normal operations (not counting things you don’t do very often), that is a strong hint that you need more RAM.

Modern Macs have high performance SSDs, so you might not notice the impact of swapping if the system isn’t doing a massive amount of it, but I would still consider it a problem, because large amounts of swapping can reduce the lifespan of an SSD.

Unfortunately, most Macs these days don’t have upgradable RAM, so if you do need an upgrade, you may have no choice but to upgrade the computer itself.

3 Likes

The relief was short-lived.
It seems that if there are diacriticals in the file name, eg:
Bedřich Smetana
or
Charivari Agréable
then double-clicking on the file to open it, or dragging the file to the application icon, “stalls” the application. Thereafter the application seems not to respond to any files until I quit and restart it.
Deleting the diacritical(s) makes the file openable as normal.
The disks are not formatted as case sensitive.
Any suggestions for things to investigate would be appreciated!

Hi there again, as far as my problem is concerned: I was mistaken, mixed up ram with dsik space, stupid me, sorry!

Weird. Apple has supported Unicode filenames for a very long time. This should just work.

Where did these file names come from? Did you type them in on the Mac? Did you type them on a non-Mac computer (Windows or Linux) and copy them to your Mac? Were they provided by a third party?

I ask because there are different ways to represent diacriticals in Unicode. If you type in a filename in macOS, they should be “normalized” - meaning they’re using the standard representation. But if the file came from a different source, then they might not be normalized, and that may be triggering a bug in macOS.

My suggestion to you:

  • If you still have the problematic files, make a backup copy. See if you can create a bug report with Apple about this. Be prepared to send them the files (if you can) if they need them for reproducing the bug. No guarantee that they will get back to you, but it can’t hurt to ask. And if they do get back to you, that will be the best possibility for fixing the bug.

  • What happens if you rename the file from the Finder, re-typing the diacriticals manually? If that works, then clearly, the file names were corrupt, and the new normalized versions work OK. If not, then there are definitely bugs in the apps that are hanging. (I think you previously wrote that you tried this).

  • The fact that BBEdit works and many other apps don’t sort of implies that there are some file APIs that work with these names and some that don’t. Which strongly implies that this is going to be a macOS bug.

You can always report your bug via Apple’s feedback site, but don’t expect to get a response from that site.

The other (probably more useful) is to file a bug report through their developer program. You need to be a registered developer, but you can create a free developer account (linked to your Apple ID) which is enough to get access to the bug reporting system. See Bug Reporting - Apple Developer.

Thank you for replying, David.
The files come from a third party, probably a Windows environment but I don’t know that…
I have tried deleting the characters with diacriticals (which usually works), but I haven’t tried re-typing the diacriticals on the Mac, that’s an interesting thought.
I suspect (fear!) that the problem is specific to my computer as I have seen no other reports of problems.
I’ll set aside some time to do some (more) testing and see if I can make a coherent bug report for Apple.

It looks as if your suggestion about the characters is correct. In the phrase:

pour choeur à cappella

it was the à which (apparently) caused the problem. I retyped the à and the file was accepted (the version above is the revised version).

On the Mac screen, both characters appear the same.

It gets curiouser and curiouser! I tried renaming a group of files with A Better Finder Rename. Dragging and dropping 22 files onto the icon in the Dock resulted in only the four files without accents in the file name appearing in the files window. Dropping the files into the ABFR window, all 22 files appeared.

The same thing happened with Metadatics: dropping all 22 files onto the Dock icon, only those files with a filename without accents appeared. Dropping them into the application window, all 22 appeared.

So two questions:
Where can I read up on the possible differences in character coding (Unicode, normalised versus not) which appear to be causing the problem?
What is the difference in the OS processes between dropping on the application icon in the Dock and into the application window?

1 Like

The first section of this article (‘The problem’) is a great explanation:

1 Like

Thank you, Jolin, I’ll read that.

1 Like

A somewhat related issue has caused problems in Ventura 13.3, hopefully fixed in 13.4

https://discussions.apple.com/thread/254748658?answerId=259052196022&page=1

That’s interesting, Tom, thank you. That suggests that this might actually be a bug. If so it has been a real time-waster. I’m not on Ventura yet, I’m a late adopter :wink: I usually wait until version X+1 is released before updating to X, but it’s curious that the timing of the problem in Ventura and what I have seen was similar.

I still find it odd that there’s no discussion of the problem in Monterey.

1 Like

Howard’s Apfelstrudel application reveals that the file names are in the composed form. Converting it to the non-composed form (using Apfelstrudel) allows the file to behave normally.

This seems to suggest that the bug(s) lie either in the handling of file names by the different destination applications, and / or in the handling of file names by the OS as they are passed to the applications.

That there is a difference in behaviour depending on whether I drag and drop files into an application window, or onto it’s Dock icon, suggests to me that the problem is in the OS.

3 Likes

It could also be that whether or not the OS normalises the filename depends on whether you drop onto the application window or the Dock, but the bug is still in the application. If the application has a bug that can’t handle one form of the filename, then the bug will only be activated in one case, even though there’s not a bug in the OS, just different behaviour. This is pure conjecture. Of course, this really shouldn’t happen at all, whatever the interplay and location of the bug is!

1 Like