Poor management of RAM with publisher

[notabene34]

Hi there
I have been using the Affinity suite for almost 2 years now. I am an old user of the Adobe suite since 1990. I was employed in a printing company or I did layout. I have been retired for 5 years but I continue to work on my own as an auto entrepreneur. Now the cost of the subscription to the Adobe suite has become prohibitive for me, that's why I invested in the Affinity suite which gives me full satisfaction so far. On the other hand, there is a big problem with RAM management with Publisher. Indeed until now I worked on small projects but I have an old work laid out with InDesign to redo. It is a catalog in A4 format of 92 pages including many photos. So I opened the Indesign file in IDML format with Publisher but it's not possible because the RAM used by the software exceeds 10.33 GB while the same version under Indesign is only 1.83 GB! Everything is blocked and impossible to get out of it other than by the forced stop of Publisher. I have a 2021 Imac 24 inch M1 with 8 GB of ram. On the Affinity site, I can't find any information on the minimum configuration required. Will I have to go back to the Adobe suite? Separate my work into several documents? I am really very disappointed by this poor management of RAM.
Does anyone have any idea how to get me out of this problem?
Thank you all

[v_kyr]

Well Publisher is (sadly) know to be a memory hog. - In your case you can try out if exporting from Indesign as PDF and importing that then in APub makes any difference here in terms of overall memory usage. Other than that, seperating the Indesign doc then exported as chunks and trying to work with several docs and in the end combine those might be another way to try out and possibly to overcome with those APub memory problems.

[Pšenda]

5 hours ago, notabene34 said:

including many photos

Are the photos embedded using Linked or Embedded?
To work on the document, smaller (and more memory-saving) photo previews could be attached, and the originals would be replaced only before the final export/printing.

[MikeTO]

I'm unsure why your smaller book is using so much RAM but as Psenda asked, are you linking or embedding? Linking is the way to go.

My book project currently has 500 photos which are 12GB combined - I need to optimize them - and Publisher uses about 3.4 GB of RAM.

[DWright]

As @Pšendamentioned if you have a large number of embedded photos in your document each of these will be loaded into memory when the document is loaded 

[notabene34]

all my photos are linked !

[notabene34]

to follow up on this subject, I would like to point out that the creation of an A5 format file of 80 blank pages already weighs 2.37 GB! in activity monitor

[MikeTO]

1 hour ago, notabene34 said:

to follow up on this subject, I would like to point out that the creation of an A5 format file of 80 blank pages already weighs 2.37 GB! in activity monitor

For me, 80 A5 pages consumed 1.5GB and 500 pages consumed 2.1GB. I don't know why it would consume so much more for you given we're using the same version of Publisher and we're both on Apple Silicon chips. The only thing I can think of is I tried it immediately after starting Publisher - you may get different results if you've been working in the app for a while.

Regardless, I agree that's a lot of memory for blank pages but the good news is that it doesn't consume that much more if you add content to them. That 500 page document which was 2.1GB when empty was 2.8GB when I filled all the pages with dense text.

[lacerto]

I have done the same test, dropping in King James Bible plain text UTF-8 version, probably about two years ago, and now performed it again, just to see if anything has changed. This time I tested it with A5 pages, which when using 12/14.4pt Minion Pro body text with half an inch margins on all sides and no spaces between paragraphs causes about 2,500 full pages of text. On Windows 11 I used 12th gen Intel i7 with 16GB RAM and InDesign CS6 (over 10 years old 32-bit software), and on macOS Monterey 12.6 with 8GB RAM (not much RAM on either computer but plenty enough to not experience any problems when running routinely 2D graphic apps).

After having flown the text, I replaced all double paragraph breaks with temporary markers, then single paragraph breaks with spaces, and finally temporary markers with paragraph breaks to have the text flown without each line ending in a paragraph break, ending up in about 2,030 full pages of text.

The results were depressing for Affinity Publisher which would probably have performed even worse on Windows 11 on a computer with better specs, but I ran the test on macOS just to read comparable results in Activity Monitor -- and I have InDesign currently only on Windows. InDesign did the job in about 3 minutes (including initial flowing and the manual work spent in writing search replace criteria), and consumed at max about 450MB RAM, 2MB disk space and max 9% of the CPU time.

On macOS I could never finish the job because I had to stop after about half an hour when the computer had gotten quite hot and the job had not seemingly advanced anywhere and Activity Monitor showed this (note that just flowing the text worked fine, but it was processing the text that caused problems):

I have no doubts that a high-end system does perform better, but IMO this is kind of yes but no but argumentation because it seems that no matter how much there are resources, Affinity apps will hog them all, if the task is long and challenging enough, and will behave the same: stall without (practically) ever completing.

Note that for this task about 20GB RAM was used, and additionally about 30GB disk space, part of which for virtual memory, but there was still plenty of disk space left so perhaps there is a limit where at least consumption of disk space stops, at least if there are no bugs involved; but I am not sure if this behavior is buggy, or "just", as OP stated, poor memory management.

[lacerto]

I ran now the same test with Affinity Publisher on Windows 11 (the same computer on which the InDesign test was run), and the results were interesting. On the first try, when simply just placing the file by clicking on the center of the first page of the document (thus creating the text frame), the app became immediately unresponsive but basically nothing was shown in the Task Manager indicating any kind of processing going on, so the app just seemed to halt the second the large text file was imported. (The exact same behavior could be reproduced on a second time, when tried later.)

When force closed and restarted and then importing the text file by first creating a text frame, then placing the text file and after the first page was flown, applying the desired paragraph formatting for the whole text (selecting it by Ctrl + A), then flowing the whole text, the app actually performed pretty much as fast as on macOS. Replacing double paragraph breaks with markers went smoothly, as well, as did replacing of single paragraphs with spaces. But after that, replacing markers with paragraph breaks showed quick increase in resource consumption, and resulted in a crash, the following screen shot taken just before:

 

The behavior is oddly different from that shown on macOS – fairly modest, compared to total resource hogging that happens there, even if clearly more aggressive than resource consumption shown by InDesign when running the same task. The end result, app crash, was of course disappointing but general behavior was “promising” and the crash seemed surprising as everything went smoothly up to that point. As can be seen, the system memory was just about to be used at 100% level so it can be that the app crash was related to that.

As the Windows test was run having Affinity based HW acceleration turned off, but having it enabled on macOS, I reran the test on macOS, this time turning off Metal acceleration, and then the behavior was much the same as on Windows, but without a crash, so actually a very good result. The app was short times (30 to 50 seconds) unresponsive and did end up consuming about 14GB RAM (not released, it seems, until the document is closed), but without similar disk space consumption as shown earlier, and finished the task swiftly.

The conclusive marks at this point seem to be that there are at least on macOS serious problems with (possibly specifically M1 and) hardware acceleration, and on Windows either memory leaks, or problems related to a situation when RAM is exhausted (as if inability to utilize virtual memory). I would be hopeful that these kinds of errors can be fixed, but Affinity apps have suffered from the kinds of problems described here for years. When running the same tests multiple times in a row, I would not be surprised to get highly different results on individual runs, or “depending on” (as shown on Windows, when simply just different methods of placing a large text file causes very different behavior) -- so it seems that instability is a word that describes well the behavior of Affinity apps when running demanding tasks (at least when using Publisher, but I would expect similar problems also when using the other two apps for comparable tasks). On the other hand, all three apps have been remarkably stable in my use, both on Windows and macOS, and on multiple computers and OSs, when running “regular” (mostly small) tasks.

===

I just ran these tests once again on both platforms, and it seems that on macOS the text frame creation based text import method does not cause the app to become instantly unresponsive, but on Windows it consistently does. This time the other method (importing to an already created frame, then applying paragraph formatting and flowing only after that) now performed more or less the way the test runs on macOS without HW acceleration, no crash, and equally swiftly, but without exhausting RAM (on macOS the same 14GB was consumed as before), so the impression on different experiences (“depending on” miscellaneous factors not exactly known) seems to be correct.

I have not tried the test on Windows having HW acceleration turned on as it seems to cause other problems, as well. On Windows, issues related to HW acceleration are not surprising but now the Metal issues have continued on M1 based macs for about two years, which is a long time, considering that there is just one manufacturer.