2.x apps are not fully releasing unused RAM

[Bryan Rieger]

One of the things I've always appreciated with the Affinity apps was just how light on CPU and RAM resources the Affinity app were. Typically if I launch any of the Affinity apps without any documents open they come in around 650MB of memory, whereas Adobe Illustrator, and InDesign grab 1GB+ each to start, and Photoshop grabs just under 2GB without any documents open.

FYI I'm running macOS 13.5.1 on a 32GB M1 Pro using the latest non-beta versions of both the Affinity and Adobe apps.

Today I noticed my system was lagging, a LOT so I fired up Activity Monitor to see who the culprits were. The usual Adobe suspects were there, but so was Affinity Designer. I closed a bunch of open windows in both Illustrator and Designer to see if that would ease the load a little (I was only using about 24GB of my 32GB available RAM). Illustrator dropped back down to 1GB almost immediately (Photoshop reluctantly released memory in subsequent tests), but the Affinity apps only released about 25-50% of the RAM they were using. When I re-opened documents this number would climb as you would expect, but upon closing the document it didn't return to the previous usage, but instead was about 20% higher.

For instance, if both Designer and Illustrator were consuming 5GB of memory, and I closed all of the documents Illustrator would essentially return to it's start-up RAM usage of about 1GB within seconds, whereas Designer would maybe drop to 2.5GB to 3.5GB and remain there indefinitely. If I opened and closed more documents in Designer that number would continue to climb. With Illustrator RAM would increase with open documents, and then settle back to 'start-up RAM levels' as documents were closed.

While my system has lots of memory, it is a bit worrying that the more I work in the Affinity apps throughout the day the more RAM is consumed by Affinity and the slower my system becomes UNLESS I completely close the Affinity apps and then open them again regularly. It's not really noticeable if you're working in one or two documents all day, as I only discovered it as I was constantly opening and closing LOTS of documents in both Illustrator and Designer today, and after a couple of hours Designer was holding onto +8GBs of memory with no documents open with the app minimized in the doc. These also weren't big documents, most of them were <1MB (all vectors).

 

[fde101]

Was there also significant disk activity?

If not, then memory usage may not have been relevant.

Memory is there to be used - just because a lot of memory is in use doesn't directly impact system performance, in and of itself.

If the memory is being used to the point that it is forcing data to be swapped to disk, or to the point that there is not enough left over to support a reasonable cache size in the OS, then you should also be seeing disk activity to go along with it.

 

[Bryan Rieger]

There was no significant disk activity.

Yes, memory is there to be used, BUT when it's not being used it should be released at some point, not retained indefinitely. Also, if you do hold onto unused memory then you shouldn't need to grab more when I open a new document—just reuse what you've already got. This is not what is happening, as with every subsequent document I open Designer grabs yet more memory and then fails to release the majority of that new memory (in addition to everything it's already taken) when that document is closed.

Eventually, all this unused memory adds up and begins to impact other apps (and the system), and smells a little bit like a memory leak to me.

[fde101]

Yes, if the usage keeps increasing in a cycle like that, I agree that sounds very much like a memory leak.

Until it reaches the point where it is causing significant disk activity, it should at most be impacting the performance of the Affinity apps themselves, however, and not the rest of the system...

Actually, thinking a bit harder about it, macOS will actually start compressing memory before it starts swapping memory.  If there is a significant amount of compression going on to try to avoid swapping, that may also explain slower performance if enough pressure has started to build up...

[v_kyr]

1 hour ago, Bryan Rieger said:

...

Yes, memory is there to be used, BUT when it's not being used it should be released at some point, not retained indefinitely. Also, if you do hold onto unused memory then you shouldn't need to grab more when I open a new document—just reuse what you've already got. This is not what is happening, as with every subsequent document I open Designer grabs yet more memory and then fails to release the majority of that new memory (in addition to everything it's already taken) when that document is closed.

Eventually, all this unused memory adds up and begins to impact other apps (and the system), and smells a little bit like a memory leak to me.

It always also depends on what memory management techniques have been implementation wise used here, as there are different methods possible for certain prog languages (for example GCs can even be optional added to languages which usually don't come along with own languge build-in garbage collectors) ...

• Reference counting
• Tracing garbage collection
• Manual memory allocation/deallocation, aka via malloc/calloc/realloc & free ...
• ... etc.

Though if occupied memory in certain situations is never really freed up again, let's say for once opened docs which after some time have been closed, then there for sure have been some referencing var handles left over, which should have been instead removed in order to release/deallocate the by them used/occupied memory. - However, detecting memory leaks in complex software isn't always an easy task, especially without having good memory-profiler dev tools.

[v_kyr]

For macOS see also as an example ...

• Profiling an application in Mac OS X
  man sample
  man instruments
  man top
  ...

[Bryan Rieger]

Thanks folks, but I'm going to leave the profiling and debugging of this to the folks at Serif as I happily retired from development a few years back. It's easily reproducible, just open and close a bunch of documents and watch Designer's (I'm assuming Photo and Publisher behave similarly, but I haven't test them as much) memory consumption continue to climb.

[v_kyr]

6 minutes ago, Bryan Rieger said:

but I'm going to leave the profiling and debugging of this to the folks at Serif

We either way can't profile and debug to find the real memory cause internals (the exact spots) here without the project/app source code. That's what the Serif devs have to do either way, in some manner like this here ...

• Measuring Your App’s Memory Usage with Instruments

We can only inspect overall memory behavior from running app processes here and so the way you already did.

[carl123]

3 hours ago, Bryan Rieger said:

Yes, memory is there to be used, BUT when it's not being used it should be released at some point,

It's been said before, that the Affinity apps WILL release memory WHEN it is needed

I suspect this is to avoid wasting CPU resources releasing memory when the system does not need it at the time or may never need it if you have sufficient free memory for that particular use of your computer

[Bryan Rieger]

9 hours ago, carl123 said:

It's been said before, that the Affinity apps WILL release memory WHEN it is needed

Unfortunately I didn’t get the memo. I can only assume this magical event might be on the 3rd Monday of July (if it’s not raining and all the appropriate paperwork has been filed), as it not only did not release any memory, but continued to allocate itself more memory to the point of eventually impacting app and system performance.

 

[walt.farrell]

Perhaps the memory it's retaining is not associated with open documents, but with, for example, your Assets panel, or Styles panel, or Brushes panel, etc.

The categories you have used from those during your session are probably in memory.

[Bryan Rieger]

Yeah @walt.farrell, I thought about that, but in this case I was simply opening, exporting, copying, pasting, and closing LOTS of files, all of which didn’t use brushes, assets, symbols, etc - just simple vector illustrations <1MB each.

Anyway, there’s not much else to add to this thread. Either this behaviour is by design, or it’s an issue that Serif may (or may not) choose to look at some point in the future.

[v_kyr]

In the pasts when having to deal with complex Java VM based app developments and even Java has build-in memory garbage collection, I've always plugged in own memory monitoring with autoGC based freeing up memory capabilities, into huge apps and huge common Java IDEs. - Since often the VMs own memory handling occured too late or didn't performed at all at critical memory states when needed.

Example setup when plugged into in Netbeans instead of an own app (I once had made plugins for JBuilder, Eclipse and Netbeans), so for Java IDEs I often needed for development purposes.

That was always a good way to customize the overal memory usage and handling for a bunch of huge apps, as I could setup to auto free memory on certain own defined memory usage values/points. The whole gave a much snappier behavior for long day working with several Java based apps here, with a good and much better memory history overview of how much memory was occupied and when memory chunks were again released. - In addition, I was able to influence the memory release myself depending on certain memory values achieved and then control things myself! - It also helped to identify critical application states during runtime, i.e. places where optimizations in the code were still required for a better runtime behavior.

[walt.farrell]

@Bryan Rieger: what is the memory utilization when you initially start the application with no files open? And then immediately after creating a simple empty file? How do those numbers compare with what you've seen when you've done your processing and closed all the open files.

[Bryan Rieger]

18 hours ago, Bryan Rieger said:

Typically if I launch any of the Affinity apps without any documents open they come in around 650MB of memory…

On launch: 648MB, after creating a 1080 x 1080 px artboard:  1.4BG, after creating another 1080 x 1080px artboard: 1.85GB.

After closing one artboard: 1.66GB, after closing the remaining artboard: 1.38GB.

These numbers are consistent with what I've reported earlier in this thread in that the memory isn't being fully released when documents are closed. It becomes much more noticeable after you've opened and closed MANY documents.

Addendum: after sitting minimized and idle with nothing open for 30 minutes, and allowing Adobe apps to monopolize the available physical memory, Designer's memory usage did drop from 1.38GB to 1.37GB.

Note: I also don't use Assets, Styles, Symbols, etc,—in fact I delete all the built-in ones—but I do have a lot of pixel brushes that weren't available at the time (as I was in the 'Designer' persona).

Edited August 24, 2023 by Bryan Rieger
Added addendum and note.

[walt.farrell]

Some comparison numbers from my laptop Windows 11 system, for Designer 2.1.1:

1. With an empty Assets category selected before I last closed Designer, and an empty Brush category selected (both vector and raster), when I start Designer 2.1.1 it takes 1,782 MB as reported by Task Manager.
   
   On the other hand, if I close Designer while I have a large Assets category selected, and a large Brush category selected, when I start Designer 2.1.1 again it takes 2,566 MB as reported by Task Manager.
   
   Conclusion: The active (last selected) panel categories have a strong influence on the storage usage, even with no documents open. In my case, for those chosen categories in Assets and Brushes, it takes 784 MB of storage at all times.
    
2. If I then create an empty document (8.5 x 11 inches, 300 DPI), the memory usage grows to 3,227 MB.
   
   Conclusion: that empty document took another 661 MB.
    
3. If I close that document, the memory usage drops down to 3,050 MB. So it did not release all the storage, having kept 484 MB of it.
    
4. If I create another empty document (same size), I can see that the memory utilization initially drops by about 100 MB, and then finishes at 3,612 MB.
   
   Conclusion: Assuming the new document also took 661 MB, the starting point just before it was created was 2,951 MB. And 2,951 - 2566 gives a delta of 385 MB that remains unaccounted for. This could indicate some kind of leak, but it would take more detailed analysis to know if it is indeed lost or being used for something that I just don't yet understand.

[fde101]

6 hours ago, walt.farrell said:

Assuming the new document also took 661 MB

It's not really a given that the first one did.

Something else to consider is that many of the studio panels are completely disabled until a document is created.  Some of them may have outside resources they load the first time they become active, in which case any of those which are visible would add to the memory usage with the first created document, keep their data in memory, and reuse it for the next document.

Maybe the lists of presets in the Export window could be doing the same thing, being loaded the first time you open the Export window then cached from there on out - there are just too many opportunities for things to happen even after the first created document that I think it would be more meaningful to go through the routine then measure the change with the third or fourth document than it would to do so with merely the second?

[Old Bruce]

17 hours ago, Red Sands said:

I have noticed Designer using significantly longer when shutting down - only sometimes - showing the beach ball for surprisingly long. Then after many seconds it finally terminates by itself.

If you have a very large amount of data on the Clipboard it takes a while for Designer to purge/clear that from the clipboard when you shut down. One of the quirks of working with the Affinity Suite.

[walt.farrell]

44 minutes ago, Old Bruce said:

If you have a very large amount of data on the Clipboard it takes a while for Designer to purge/clear that from the clipboard when you shut down. One of the quirks of working with the Affinity Suite.

Just curious: could you copy something very small to replace the large clipboard item before you close the Affinity application, and would that make closing faster? 

And if so, couldn't Affinity do something like that rather than whatever it's doing now?

[Old Bruce]

13 minutes ago, walt.farrell said:

Just curious: could you copy something very small to replace the large clipboard item before you close the Affinity application, and would that make closing faster? 

I do just that (when I remember to do so) when I have a massive amount to data on the clipboard.

15 minutes ago, walt.farrell said:

And if so, couldn't Affinity do something like that rather than whatever it's doing now?

I guess there could be a simple "Copy a singe pixel at 0, 0" command that runs as soon as the File > Quit is chosen. But that would need an open document when you quit.

[walt.farrell]

1 hour ago, Old Bruce said:

I guess there could be a simple "Copy a singe pixel at 0, 0" command that runs as soon as the File > Quit is chosen. But that would need an open document when you quit.

I meant, if it's faster then couldn't Affinity do something like that automatically when closing the application, rather than whatever it's doing now to clear the Clipboard?

[fde101]

41 minutes ago, walt.farrell said:

I meant, if it's faster then couldn't Affinity do something like that automatically when closing the application, rather than whatever it's doing now to clear the Clipboard?

The expectation of a user should be that the clipboard is NOT cleared until the user replaces its content with something else (or the user logs out or the computer is rebooted, etc.).  It should not be a standard practice of most applications to clear the clipboard themselves (password managers being a notable exception).

I have seen a few Micro$oft apps work around this by prompting the user that there "is a large amount of data in the clipboard" and asking if it should be cleared when the user attempts to quit (exit) the application.  Annoying.

Clearing the clipboard on exit could be offered as a preference, but should clearly not be a default behavior.

[v_kyr]

• Clipboard on Mac: how to view and manage copy-paste history on macOS

• Clipboard in Windows

[Oufti]

6 hours ago, Old Bruce said:

7 hours ago, walt.farrell said:

Just curious: could you copy something very small to replace the large clipboard item before you close the Affinity application, and would that make closing faster? 

I do just that (when I remember to do so) when I have a massive amount to data on the clipboard.

When we bought our first Mac, 30 years ago, there was a free training offered to un-experimented users. Purge the clipboard twice, for example by copying a single letter in the Finder, when you've copied large amounts of data was already one of the tips they gave us.

(Copying twice is needed to completely free the memory because of Cmd-Z: to be able to cancel the copy action, and revert the clipboard to its former state, its previous content must still be saved somewhere, that has also to be cleared.) 

[fde101]

13 hours ago, Red Sands said:

I have several programs from the big players like Microsoft and Adobe that when you exit the program, they ask something like "You have left a large amount of data in the clipboard. Do you want to keep it in the clipboard?"

Yes, I mentioned those incredibly annoying prompts (which I sincerely hope Serif does NOT emulate) in my earlier post.