Object Selection Tool holding memory

[Torstein]

If I use Object selection the memory use "explodes." In the end my PC hangs and have to do a restart.  At the moment I'm at 61 it's using 11GB.... Just let me fix a bit more and I'm sure my PC stops again.... On other photos before I have not experienced any problems. Maybe it's the complex shapes that and all the layers and masking I'm adding?

I just closed the photo, and I can still see that AP still holds 10GB of memory. Should it not release the memory without me closing the app?

[fde101]

On 11/1/2024 at 7:00 PM, Torstein said:

Should it not release the memory without me closing the app?

Not necessarily.  

First, when allocating memory for a document, the app needs to allocate memory from the host operating system to make it usable in the app, then it needs to allocate memory from the app to the document.  It is more than possible that the app was designed to keep most of the memory it received from the host operating system to reuse later on for other documents, as memory allocation is (in computer terms) a slow process and needing to reallocate memory from the operating system all the time can add up, so they may simply be holding it internally for reuse so they can skip that step the next time - in other words, closing the document may have freed the memory to be reused by the app, but it is still allocated from the operating system, so the operating system reports it as used (which is correct from its perspective).  Way back in my college days, learning computer science, this is how I was taught to build memory allocation routines (once you have the memory keep it and build your own list when deallocating it rather than returning it to the OS, to reuse it later) for performance reasons.  This is not always the best approach, but it is a valid one in some cases.

Second, it is likely that some portion of the memory the apps use is actually used to load and cache data that is independent of the document itself (such as holding a perhaps decompressed version of the model if it is downloaded in a compressed form, rendered font outlines, thumbnails of images in the assets panel if you opened that, etc.), and that kind of data may similarly be reusable with later documents.  If this kind of data is loaded or initialized the first time it is accessed, then keeping it loaded after that first use would increase the memory use of the app until the app closed rather than until the document closed (and this kind of "load on first use" behavior is a VERY common practice in software engineering).

[EmT]

Hi @Torstein

Could you provide a copy of your file so we can investigate please. 

[Torstein]

On 11/4/2024 at 10:42 AM, fde101 said:

Not necessarily.  

First, when allocating memory for a document, the app needs to allocate memory from the host operating system to make it usable in the app, then it needs to allocate memory from the app to the document.  It is more than possible that the app was designed to keep most of the memory it received from the host operating system to reuse later on for other documents, as memory allocation is (in computer terms) a slow process and needing to reallocate memory from the operating system all the time can add up, so they may simply be holding it internally for reuse so they can skip that step the next time - in other words, closing the document may have freed the memory to be reused by the app, but it is still allocated from the operating system, so the operating system reports it as used (which is correct from its perspective).  Way back in my college days, learning computer science, this is how I was taught to build memory allocation routines (once you have the memory keep it and build your own list when deallocating it rather than returning it to the OS, to reuse it later) for performance reasons.  This is not always the best approach, but it is a valid one in some cases.

Second, it is likely that some portion of the memory the apps use is actually used to load and cache data that is independent of the document itself (such as holding a perhaps decompressed version of the model if it is downloaded in a compressed form, rendered font outlines, thumbnails of images in the assets panel if you opened that, etc.), and that kind of data may similarly be reusable with later documents.  If this kind of data is loaded or initialized the first time it is accessed, then keeping it loaded after that first use would increase the memory use of the app until the app closed rather than until the document closed (and this kind of "load on first use" behavior is a VERY common practice in software engineering).

I still would prefer and think it should release the memory taken, even if it takes some time, when closing a photo where subject recognition is used. The amount of RAM used is simply too large to let it stay.

I have also experienced several computer lock ups using AP2 Beta whish may happen because of this. Of course there can also be other reasons, maybe my old lowly RTX2060 with 6GB simply cannot handle the large memory demands. I have now switched too only use CPU for this function. 

[Torstein]

On 11/4/2024 at 11:09 AM, EmT said:

Hi @Torstein

Could you provide a copy of your file so we can investigate please. 

Sorry I'm so slow to respond, but it's been a busy week.  The attached file is the one where I got to crash badly. Hope it helps. The crash that locks my PC totally came after a lot of selection messing and then made "Merge Visible" So of course I had a few layers and did different adjustments like Curves etc.

hangarskip.afphoto

[Affinity Info Bot]

An issue raised in this thread ("Memory in use increases when using Object Selection or Selection Subject and is not released until session is closed") has now been reported to the developers by the testing team (Ref: AF-5095). Thank you very much for reporting this issue to us.