Affinity Photo keeps crashing while loading assets

[Affinity Rat]

Just upgraded my PC from 16 gb memory to 32gb and thot I would see how well the desktop version compares with my iPad Pro version.

Well doesnt look good, my PC crashes everytime loading same asset file my iPad can handle.

On PC, Apho V1 memory usage gets to about 8gb then crashes, after the crash reloading shows the category loaded, with no visible content.

I assume this has not ben fixed for APho V1, and I wont upgrade to V2 because I hate the UI. 

[Affinity Rat]

More observations, obviously assets are compressed, on my PC loading assets my CPU jumps to about 70+ % usage and memory hit about 12gb of 32gb and then crashes.

After loading assets, and deleting the category, memory is not reclaimed until exiting APho and reloading the app.

Asset file attempted loading on PC is about 460mb before crashing, my iPad can load a 760mb asset file, slow but no problems.

 

 

 

[walt.farrell]

If you have Hardware Acceleration (OpenCL) enabled in Preferences/Performance, does turning it off help?

[Affinity Rat]

Thanx Walt, the OCL was enabled, but I only have 4gb video ram, but I was unaware there were also ram constraints, it was set to 8gb, upping to 28gb fixed the problem at least with a 760mb asset file.

[Affinity Rat]

While it is working now that I allocated more ram, it is remarkable slow compared to my iPad, disk speed hardly used, ram usage creeps up slowly, cpu  never >80%, I would say ipad is faster on large asset files. This surprized me.

Of note though… after loading a large asset file then deleting it ram is Not recovered, after loading large asset file my ram usage goes up to my limit 28gb, if I subsequently delete the category ram stays at 28 gb so if I load another large file the app will crash, looks like no ram left for 2nd file because ram not released and available after category deletion.

Lesson learned after using a large asset file, delete the category, save and restart app to recover ram.

[markw]

First I must say I have no idea what might be slowing your Asset file loading or causing crashes…?
But I am wondering if there is maybe something or things contained in your Assets file that is affecting AP?
My Asset file in AD2 is currently 958MB and as far as I can tell has no great impact on Photo’s performance or over hogging RAM.
My RAM usage in Photo’s Prefs is set to the same as my system i.e. 16GB.

 

[walt.farrell]

I have a 7 GB assets.propcol file on my Windows laptop, and switching between categories (or adding/deleting categories, or adding Assets, or sometimes creating new files) can be noticeably slow but a significant portion of that time is spent in reading/writing assets.propcol, if I've measured it correctly.

[Lee_T]

43 minutes ago, Affinity Rat said:

While it is working now that I allocated more ram, it is remarkable slow compared to my iPad, disk speed hardly used, ram usage creeps up slowly, cpu  never >80%, I would say ipad is faster on large asset files. This surprized me.

Of note though… after loading a large asset file then deleting it ram is Not recovered, after loading large asset file my ram usage goes up to my limit 28gb, if I subsequently delete the category ram stays at 28 gb so if I load another large file the app will crash, looks like no ram left for 2nd file because ram not released and available after category deletion.

Lesson learned after using a large asset file, delete the category, save and restart app to recover ram.

The RAM used is low priority, and can be written over by the operating system as required, unused RAM is wasted RAM. As your software has no idea of your intentions, it would not know that you do not need to use these assets again, so the best way to operate is to hold these in RAM which is much faster than pulling again from disk into RAM. If you do not use these again, and you have no spare RAM, the software (and any software on your computer, can overwrite these files.

It's a common misconception that free RAM is a good thing. Recovering RAM will invariably slow things down as things that do need to be cached in RAM will once again need to pull from the slower physical drive.

Lee

 

[Affinity Rat]

1 hour ago, Lee_T said:

The RAM used is low priority, and can be written over by the operating system as required, unused RAM is wasted RAM. As your software has no idea of your intentions

Well it seems to me if you delete a category, it implies ram utilized for that category is no longer needed.

No debate about loading from disk/cache slower than ram, but my experience with this app is when the ram limit set in the app is exceeded the app crashes, and providing more ram allows the app to load bigger asset files, but still crashes if the app ram limit is exceeded.

 

 

[Affinity Rat]

2 hours ago, markw said:

First I must say I have no idea what might be slowing your Asset file loading or causing crashes…?
But I am wondering if there is maybe something or things contained in your Assets file that is affecting AP?

It could be that instances within my asset file have not been completely rasterized, ie there are layers present, thereby requiring more grunt and more resource hungry.

[Affinity Rat]

1 hour ago, walt.farrell said:

I have a 7 GB assets.propcol file on my Windows laptop, and switching between categories (or adding/deleting categories, or adding Assets, or sometimes creating new files) can be noticeably slow but a significant portion of that time is spent in reading/writing assets.propcol, if I've measured it correctly.

Yeah I watched the disk usage (fast ssd) during loading, it didnt appear to be a factor, but certainly ram usage increased relatively slowly. 32gb @3200MHz, but only 4gb video ram.

[walt.farrell]

16 minutes ago, Affinity Rat said:

Well it seems to me if you delete a category, it implies ram utilized for that category is no longer needed.

I think that Lee was indicating that the OS or other applications can use the RAM if they need it, but Affinity can also (re)use the RAM for other things if it wants to. Essentially, it has been marked as "free for others to steal" but can still be used by Affinity when it wants to (at which point, presumably, Affinity marks it as "in use" so the OS and other applications can't steal it).

[Affinity Rat]

10 minutes ago, walt.farrell said:

I think that Lee was indicating that the OS or other applications can use the RAM if they need it, but Affinity can also (re)use the RAM for other things if it wants to. Essentially, it has been marked as "free for others to steal" but can still be used by Affinity when it wants to (at which point, presumably, Affinity marks it as "in use" so the OS and other applications can't steal it).

So does the app ram limit, ensure that only the affinity app has access to that ram and should clear some of that ram to cache perhaps when more ram is demanded? while other system processes do not have access to that ram. The system runs on the residual ram. I have 32gb and I set app limit to 28gb, can the system share that 28 gb or must it run in the 4 gb remaining  “free ram”

All I have observed is when the ram limit is exceeded the app crashes.

[walt.farrell]

Sorry, I have no idea, @Affinity Rat.

[Affinity Rat]

3 hours ago, Lee_T said:

The RAM used is low priority, and can be written over by the operating system as required…

I interpret that to mean the app ram limit, does Not exclusively reserve ram for the app, if this is true what does the app ram limit do?

 

[R C-R]

2 hours ago, Affinity Rat said:

I interpret that to mean the app ram limit, does Not exclusively reserve ram for the app, if this is true what does the app ram limit do?

EDIT: I just noticed the OP is a Windows user, but I'll leave the macOS related stuff here because I think there is something similar to wired memory in Windows.

The only memory that can't be cached to disk is the wired memory the macOS system needs to operate -- more about that & memory usage in general can be found in this Apple article, including a bit about why memory remains cached to improve performance, & why you can't force the system to use less memory than it needs.

As I understand it, the RAM limit in the Affinity apps is provided to be able to 'tune' the app to use less memory that it otherwise might when a user is running the Affinity app plus other memory-hungry apps simultaneously, thus potentially reducing disk thrashing. But it may have other uses as well, because it is sometimes suggested that reducing it from the default has helped prevent certain odd behaviors, instabilities, & maybe even some obscure causes of crashes.

[Affinity Rat]

13 hours ago, R C-R said:

EDIT: I just noticed the OP is a Windows user, but I'll leave the macOS related stuff here because I think there is something similar to wired memory in Windows.

The only memory that can't be cached to disk is the wired memory the macOS system needs to operate -- more about that & memory usage in general can be found in this Apple article, including a bit about why memory remains cached to improve performance, & why you can't force the system to use less memory than it needs.

As I understand it, the RAM limit in the Affinity apps is provided to be able to 'tune' the app to use less memory that it otherwise might when a user is running the Affinity app plus other memory-hungry apps simultaneously, thus potentially reducing disk thrashing. But it may have other uses as well, because it is sometimes suggested that reducing it from the default has helped prevent certain odd behaviors, instabilities, & maybe even some obscure causes of crashes.

Thank you, so you are suggesting the purpose of the app ram limit is to prevent the app (Apho in this case), from hogging system resources in lieu of creating an safe environment for the app to operate without being disturbed by other pesky resource demanding services/apps et al.

[R C-R]

1 hour ago, Affinity Rat said:

Thank you, so you are suggesting the purpose of the app ram limit is to prevent the app (Apho in this case), from hogging system resources in lieu of creating an safe environment for the app to operate without being disturbed by other pesky resource demanding services/apps et al.

Not exactly. The idea is that by limiting the amount of RAM AP uses (which will in some cases reduce its performance) this will allow other apps that are being run at the same time to perform better because there will be more RAM available for them to use before any of their data has to be paged out of RAM.