Publisher - Massive RAM usage while saving/accessing resource manager.

[nPoika]

Hi there,

I'm currently in the process of getting Affinity rolled out in lieu of the Adobe suite in my architectural practice. So far it's been fairly seemless, and fairly well recieved. However I have one masterplanning report being made in Publisher that is practically unusable. The report itself isn't particularly large, about 25 A3 pages @ 72dpi with a mix of PDFs, JPEGS, Designer and Photo files, all of which are linked.  There's nothing atypical to this report compared to any other report we'd conduct. However the following behavious occurs:

When saving the file, or opening the resource manager Publisher becomes unresponsive, while doing so it maxes out the available ram (I have 32gb, this should be plenty).  Once the ram is maxed out it also starts to use the scratch disk, shown here at 40MB/s but I have had previous instances where it's at 350MB/s.  It's worth noting, that if you leave the PC long enough (between 20-30 minutes) it will eventually achieve the command, but this isn't practical, nor does this behavious cease upon a successful completion. I tested it in the beta, and the beta would just crash trying to open the file.

This happens on multiple machines. 

My specs are:

CPU: i7 9700K

RAM: 32GB DDR 4 RAM

HD: 2TB QVO SSD

GPU: RTX 2070

See attached a screenshot of Task Manager during this issue. 

 

 

 

Edited October 22, 2020 by nPoika
Sorry! Accidentally hit submit!

[carl123]

2 hours ago, nPoika said:

The report itself isn't particularly large, about 25 A3 pages @ 72dpi with a mix of PDFs, JPEGS, Designer and Photo files, all of which are linked.

Do you have a rough estimate of the total size of all the linked files?

Are one or two of those files particularly large and accounting for a large proportion of the total size, and if yes how big are they?

[nPoika]

Hi there, thanks for the reply! 

At a guess, less than 150mb. There was one PDF linked that was approximatley 77mb and very heavy (externally created). I have since deleted that out, and there has been no change to the behaviour mentioned above. Most items are jpgs/pngs with some PDFS created by a mix of Photo and Designer. And some designer files linked directly for smaller diagrams and such.

It's worth noting that this issue is really two. It's a problem to have this within a file, but my bigger concern is  that the program practically breaks, signficantly hindering troubleshooting. 

 

 

[carl123]

If it was me, I would start by removing all linked files to a new folder, then adding them back in groups to see if I could identify a particular file that was causing the problem.

I have in the past found corrupt files this way, that were crashing my app

Alternatively, you may have to wait until Serif opens later today then send them the document plus all linked files for them to investigate and see if they can recreate the problem

 

[Gabe]

Hi @nPoika,

Sorry for the delayed reply and welcome to the forums. 

Can you use this link to upload your afpub file along with all your non-system default fonts and any linked resources? https://www.dropbox.com/request/QOOLiIE7F13EZbwDtPzO

[nPoika]

Hi There,

 

Sorry assumed this had been forgotten. Sorry it's not practical to do so, resources are scattered accross our directory structure and Publisher doesn't have a package function in the main release. 

I don't mean to gripe about this, but I am experiencing this level of instability across multiple documents, where replicating the situation in InDesign CS5 does not present an issue. I appreciate that we are an architectural practice and as such will often have heavier assets than many other use cases, however it is becoming clear that this software may not be suitable for our practice. Which is a shame as we had the intention of rolling it out to all approximatley 25 staff members. 

Ultimately, the resource manager is not up to scratch. It is the one utility that should work in all situations, it shouldn't freeze due to heavy assets. It shouldn't consume all the RAM availble on the computer just because it finds a file it does not like. It is a useful tool for us to troubleshoot which files may be corrupt, or causing issue, which ones may be too heavy and need to be optimised. 

It's the view of my practice these needs to be fixed before we can even consider a more widespread rollout. Which is disappointing, because we genuinely like the software otherwise. 

[EmilyGoater]

@nPoikaI've sent you a message about this, please reply when you can. Kind thanks again. 

[Gabe]

And here's a new upload: https://www.dropbox.com/request/alWkEMI0BsCm628nsQpC