Jump to content
You must now use your email address to sign in [click for more info] ×

Performance tab in preferencens - what affects what?


Recommended Posts

With more complex Publisher documents, I sometimes experience crashes just moving about in the document..

I have a feeling that the crashes are related to settings in the Performance section of the Preferences, but I can't find anywhere a FAQ or a comprehensive discussion on what the different choices really mean for the stability and performance of the app. A few questions:

  1. In the Display section, which is more stable: Metal, OpenGL, OpenGL (Basic) or Software rendering? I suppose Metal is fastest, or am I wrong?
  2. Does clicking "Use only integrated GPU" affect anything, especially as I only have an integrated GPU in my Mac Mini.
  3. What Does "integrated" refer to: Intel integrated graphics on the chip, or Integrated, as in "internal" as opposed to an eGPU?
  4. What effect has lowering or enlarging the RAM usage limit? Is 6 GB enough for more complex documents? Is it a good idea pushing the limit way over installed physical RAM size (I have 16 GB physical RAM installed)? Shouldn't apps allocate memory dynamically, anyway? Why am supposed to fiddle around with this?
  5. Does View quality affect the stablity of the app, since one would assume better quality would be more taxing on many resources?
  6. Does hardware acceleration/Metal compute really work in any meaningful way on Intel integrated graphics, with its paltry 1,5 GB RAM, which it allocates from main memory?

So many questions, I know. 

Link to comment
Share on other sites

Ok, so I seem to have found at least a partial solution: Just allocate a lot of RAM to Publisher!

I have 16 GB physical installed, and I had around 7 GB allocated to Publisher. With everything else the same,  I bumped Publishers memory allocation to a generous 18 GB (i.e. far exceeding the physical RAM limit) – and everything seems to run smoothly. Publisher also feels much snappier over all, when moving about in big documents.

I must have had some old information in the back of my head, telling me to never allocate more than free available physical RAM (with a couple of other programs running at the same time). But this tip seems dated. Apparently virtual memory, or compressed memory, or some other sort of memory management sees to it that this "crazy" setting works.

Link to comment
Share on other sites

 

9 hours ago, Rabari said:

Publisher also feels much snappier over all, when moving about in big documents

If restricting Publisher's memory to 7GB was causing Publisher to use virtual memory then that would always be slower than allocating more memory to Publisher if it was available.

I doubt allocating 18GB on your 16GB system did anything special and I suspect Publisher simply defaulted to using the maximum amount of memory in your system (i.e. 16GB)

But none of the above really explains the crashes in your opening post.  Publisher should never crash. 

If you have crash reports uploading them will/might help the Devs determine the cause.

To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.

Link to comment
Share on other sites

I see your point, but I often start Publisher when I already have a several other porgrams running, like Affinty Photo, Affinity Designer, Safari, Mail, Apple Photos and a slew of smaller helper apps. At that point there is no available free physical RAM, according to an app like Memory Diag. What kind of memory does MacOS then allocate, and what kind of memory does Publisher use at that point? And how does the settings in the Performance tab relate to a situation like this? It would be really interesting to hear from the devs about this.

No app should of course crash. When I experience crashes i try to pinpoint what I was doing. Evidently the last crashes had something to do with me using a few HEIC images. They import and display fine, but seem to cause trouble in memory tight conditions, and also generate errors when exporting to pdf. In another instance I had to change a greyscale tiff (over 5000 px width, but scaled down, so that the Resource Manager could not even display a value for Placed dpi) to a smaller png. Worked thereafter.

Link to comment
Share on other sites

  • Staff

Hi Rabari,  

If possible could you provide a screen recording of the app crashing? If possible could you also provide the HEIC images that are causing one of the crashes?

Thanks

Callum

Please tag me using @ in your reply so I can be sure to respond ASAP.

Link to comment
Share on other sites

23 hours ago, Rabari said:

Apparently virtual memory, or compressed memory, or some other sort of memory management sees to it that this "crazy" setting works.

The Mac memory manager does make sure this works but explaining in detail how is too complex to do in a forum post. You can find articles on the web like this one that explain more about memory compression, but the most important thing to understand is that the memory manager will never allow so much RAM to be used by any application level process that there is not enough left to run system level functions.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

13 hours ago, Rabari said:

No app should of course crash. When I experience crashes i try to pinpoint what I was doing. Evidently the last crashes had something to do with me using a few HEIC images. They import and display fine, but seem to cause trouble in memory tight conditions, and also generate errors when exporting to pdf.

When an app crashes it usually generates a core dump with an exception backtrace (see: app crash reports here). This report together with infos about the usage scenario, which caused that crash behavior, is always useful to know and see for app developers. So they have a chance to reproduce the whole and in order to find the cause of all evil in the app's source code.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.