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

Very sluggish performance with lots of text loaded


Recommended Posts

On a fairly new i7 machine with 64GB RAM.

With 200+ A4 pages worth of text loaded, Publisher becomes very sluggish when you edit text frames on master pages, e.g. resize them.

The whole thing becomes so slow it's hard to make precise changes.

I assume it's because of AP updating the whole publication while you work on the frames(?) 

Link to comment
Share on other sites

  • Staff

This can often be down to a graphic element having a complicated wrap outline (it may be a vector or png).

If you do have such a graphic select it, open the text wrap settings dialog and then simply close it. This should cache the outline and lead to much better performance.

Link to comment
Share on other sites

I've had a similar problem when using the 'place' option, (from word docx) to import 400 pages of text (no graphics or other special features). The program becomes so slow as to make operating it successfully very frustrating. For example when resizing my text boxes to fit guidelines, it always (not often but always tends to freeze for some seconds.  To give you more of an example, if I adjust any text box to meet guidelines, scrolling up or down simply won't occur for several seconds. Likewise if I wish to right click on a word to correct the spelling or when I wish to enter new text manually. 

I should think its not related to my computer performance as I'm running this on a pretty decent i7 laptop.

Any suggestions on how this issue can be resolved would be highly appreciated. 

Thanks 

 (Please note: the text involved is private and cannot be shared unfortunately) 

 

Link to comment
Share on other sites

  • 4 months later...

@Pauls

Apologies if there's a newer thread on this I didn't see, but I've also had this issue. It seems to be happier if I type the dimensions in the transform panel than if I drag; I assume it's resizing all applied pages every mouse move event, even if there are several in rapid succession.

If you're still looking for files, I can submit the docx I'm using. It's an RPG rulebook, so it's over 330 pages before layout, with most images and a few tables omitted at that stage. It imports slowly, adjusts master page text frames slowly, messes up at least some of the paragraph/heading styles, seems to have real performance trouble autoflowing (especially if the pages to flow into don't exist yet), and can't autoflow at all past a certain large table (it just makes a zillion blank pages from that point on; maybe it chokes if the table would take more than one page on import).

Link to comment
Share on other sites

I've uploaded a big ol' Word doc. I've noticed that if I delete the big table of human special abilities that starts on page 70 and the big table of shapeshifter weaknesses that starts on page 81, it has fewer problems importing and flowing, though it's still extremely CPU intensive and sluggish to work with or autoflow.

Link to comment
Share on other sites

I am also experiencing VERY SLUGGISH performance on Windows.  My document is only 249 pages, part of the text imported from Word.  I am also not at liberty to share the document.  At this point I have images/graphics in about a third of the document, but need to load a lot more - the project calls for images/graphics on almost every page.  I'm concerned that the project will not be finished on deadline because Affinity Publisher is delaying the work.  Every time I edit text, drag a graphic, reformat text -- pretty much anything, there is a delay of 2-10 seconds.  I never know if a graphic will move when I want it to, and if it does, if it will freeze mid-drag.  I'm contemplating moving back into Word.  Considering how much more elegant Publisher is, that would just drive me mad.  But I may have to do it to make the deadline.

I'm using an i5-7200U CPU with 8.00 GB RAM, a 64-bit OS, x64-based processor.  Let me know if other details would be useful. 

If you can fix this in time, I'll be so very grateful!

Link to comment
Share on other sites

@Pauls I might have found the problem(s) in my case.

  1. I started rebuilding the project, copy-pasting stuff from the slow one's master pages, and I noticed that master page B, which inherited from A, had images (in frames) in its master A layer. These images were also in its own layers, resulting in several duplicate, partially-transparent images on top of each other. (I had previously moved the images out of A into B when I made B, so I don't know why B was still inheriting them from A in addition to having them itself.) Once I deleted those duplicate, overlapping images, the CPU usage dropped, and the project became more responsive. I was able to place the word doc (very similar to the one I sent) and autoflow just fine. Master B had been applied to maybe 50 out of 400 pages.
  2. I continued with the clean/rebuilt project anyway, just to be safe. When I turned the document baseline grid on, CPU usage shot up again, and the project became very sluggish, just like the old project. (I had been using document baseline grid in the old project as well.) The CPU and lag stick around; they don't just stop once it's finished aligning things (unless it's taking a very, very long time to do that). The CPU and lag persist if I delete the text from pages 5-400 so that almost every page is blank. It appears just having enough text frames and baseline grid enabled causes problems. If I turn the baseline grid back off, it becomes responsive again. (I checked this in both the new and old projects; both now behave this way.)

As a side note, I tried doing baseline grid via the text frames on a master page, and that setting doesn't seem to propagate to the pages that use that master. I have to do it individually (by editing detached) or by using the document baseline grid.

I'm also confused by text leading being ignored for the first line in a column. Maybe that's normal? But it makes it so I have to turn on the baseline grid to get things to line up, since I have headings that are different heights than the body text.

Link to comment
Share on other sites

For what it's worth, the closest workaround I've found for avoiding baseline grid (if it's causing performance issues for anyone else) is to set the master page text frames to balance text in columns and bottom-align text. Then, if I've got widow and orphan control and spacing set right for my heading and body styles, I get basically the same effect without the performance hit. The only catch is that any pages with extra space will have that space at the top instead of bottom and may need have the frames manually adjusted. Example of the results on a spread with a bit more extra space than I'd like:

image.thumb.png.6a0f768d6996d7f49e57be5925039a3f.png

Link to comment
Share on other sites

  • 2 weeks later...

I tried turning off the baseline grid, but that didn't change anything.  I also tried deleting the guidelines on all 235 pages (which for some reason has to be done on each page individually), as well as disconnecting my external monitor.  Neither of these helped, either.  I appreciate any help I can get with this!

Link to comment
Share on other sites

Interesting. I wonder what the cause is in your case? Does your project have any place where a clean page break can be inserted? (For example, at the end of a chapter.) For mine, I'm going to try splitting my text frame flow at those points to see if having multiple sets of a few dozen linked frames performs better than having a single set of hundreds of linked frames. (But I'll have to be sure it doesn't break things like hyperlinks.) I haven't tried this yet, but if the slowness happens because it has to check if each change affects hundreds of linked frames, it might help.

Link to comment
Share on other sites

That's one of the strange things.  I created this document with a different text frame for each chapter, so I would assume that there wouldn't be ten seconds' worth of work to do each time I edit the text or re-position an image or add a caption.... I

Link to comment
Share on other sites

New data!  I have found a workaround.  Publisher only exhibits this sluggish behavior when the Pages tool is active (visible).  I had come to rely on this view for navigation, but when it is active and visible, the whole program gets bogged down - as I reported above, approximately 10 second delays when I make any kind of edit - text, graphics, layout -- anything.  But as long as I have some other tool open instead, the program is responsive.  To be clear, I can have the Pages tool selected under View -> Studio, so the Pages tab is visible, but some other tab is selected (such as TOC or Fnd).  This solves my problem -- but I wonder if there is some way the issue could be corrected, so that I can have the Pages tool active and still be productive...?  Not an urgent problem for me at this point, but still a wish-list item!  I'm attaching a couple of screen shots to make sure I'm communicating.

In this first one, Pages is visible as a tab, and the tab is open (this way the program is very, very sluggish):

Pages-Active.png.5c025b9e44adcdd29dd55079de22149f.png

In the next one, Pages is still visible as a tab, but Table of Contents is active (this way the program is downright snappy - very responsive):

Pages-Inactive.png.c81d73f20c15d93a46e6860dfcdd8d80.png

Thank you to all who considered/will consider the problem.

Link to comment
Share on other sites

@JCEyre Interesting! There's a performance option for nearest neighbor vs bilinear (I think?) rendering or previewing or some such thing. Does the pages panel affect performance differently if you switch that setting? (I'm not sure what all that setting applies to.)

Edit: It's in the Publisher preferences menu under performance, if I recall correctly.

Link to comment
Share on other sites

35 minutes ago, JCEyre said:

New data!  I have found a workaround.  Publisher only exhibits this sluggish behavior when the Pages tool is active (visible).  I had come to rely on this view for navigation, but when it is active and visible, the whole program gets bogged down - as I reported above, approximately 10 second delays when I make any kind of edit - text, graphics, layout -- anything.  But as long as I have some other tool open instead, the program is responsive.  To be clear, I can have the Pages tool selected under View -> Studio, so the Pages tab is visible, but some other tab is selected (such as TOC or Fnd).  This solves my problem -- but I wonder if there is some way the issue could be corrected, so that I can have the Pages tool active and still be productive...?  Not an urgent problem for me at this point, but still a wish-list item!  I'm attaching a couple of screen shots to make sure I'm communicating.

In this first one, Pages is visible as a tab, and the tab is open (this way the program is very, very sluggish):

In the next one, Pages is still visible as a tab, but Table of Contents is active (this way the program is downright snappy - very responsive):

@JCEyre, I thought I found the answer to my problem, but it still is as bad as ever for me. What's weird is that it only does it on certain days, like yesterday the very file I'm working on today was great! Very snappy & right with it performance. This morning it's slower than molasses in January!  :29_smirk: & my document is only 2 whole pages, with 2 pictures per page, & not an extreme amount of text, either. Page size is 5.5" x 8.5". The only thing I did to it today was adding an arrow & a few words. CPU maxes out & I sit there watching it think about & slowly it moves the object, one jerk at a time. (Which gives you wonderful precision!;))

Is there anything to be done for it, anybody?

Link to comment
Share on other sites

@Chul Wow, that's a small document to be lagging! Have you tried messing with performance settings and turning off baseline grid (if you're using one)? I've also noticed that sometimes Publisher doesn't play nice with other programs. You could try closing non-essentials, especially if any of them seem to have high CPU usage while Publisher's open or if you're over 90% RAM usage. (For me, LibreOffice occasionally gets stuck using a bunch of CPU while Publisher is open, so I try not to leave them both open at the same time. It's weird.)

For moving objects when it's being slow, you might try typing values in the transform panel directly instead of dragging. You'll still probably have to try a few numbers to find the right spot, but you may do less waiting.

Link to comment
Share on other sites

@Tegwyn Granted! Usually it won't make a problem for me, like I said. Last week it did it too, but that was a slightly larger document, 10 pages with lots of pics & text. I tried quite a few things & found out that if I eject the SD card I had in my computer, it made quite a bit of difference. Why? I have no clue. All I cared was that it was faster.:)

10 minutes ago, Tegwyn said:

@Chul Wow, that's a small document to be lagging! Have you tried messing with performance settings and turning off baseline grid (if you're using one)?

I did. Very little if any difference. I'm not using baseline grid (wish I were then I could (maybe) blame it on that)! :10_wink: lol.

 

12 minutes ago, Tegwyn said:

For moving objects when it's being slow, you might try typing values in the transform panel directly instead of dragging. You'll still probably have to try a few numbers to find the right spot, but you may do less waiting.

Great idea, thanks!

Link to comment
Share on other sites

4 hours ago, Tegwyn said:

@JCEyre Interesting! There's a performance option for nearest neighbor vs bilinear (I think?) rendering or previewing or some such thing. Does the pages panel affect performance differently if you switch that setting? (I'm not sure what all that setting applies to.)

Edit: It's in the Publisher preferences menu under performance, if I recall correctly.

Thank you for the suggestion!  I tried it!  Although it did improve the performance while the Pages tab is open, there was still a delay of between 2 and 5 seconds -- 2 for "lesser" edits such as a word or two of text, or even typing a whole caption, but 5 or so for setting wrap on a newly inserted text box or image, or moving an image. 

It's not such a hardship to just work with the TOC or FND tab open instead.  I am only opening the Pages tab when I really need it, and that isn't really that often. I'm pretty sure the wonderful developers at Affinity will eventually get all of the kinks worked out.  In the mean time, this is working.

Link to comment
Share on other sites

  • 3 months later...
  • Staff
On 11/1/2019 at 4:16 AM, Tegwyn said:

@Pauls I might have found the problem(s) in my case.

  1. I started rebuilding the project, copy-pasting stuff from the slow one's master pages, and I noticed that master page B, which inherited from A, had images (in frames) in its master A layer. These images were also in its own layers, resulting in several duplicate, partially-transparent images on top of each other. (I had previously moved the images out of A into B when I made B, so I don't know why B was still inheriting them from A in addition to having them itself.) Once I deleted those duplicate, overlapping images, the CPU usage dropped, and the project became more responsive. I was able to place the word doc (very similar to the one I sent) and autoflow just fine. Master B had been applied to maybe 50 out of 400 pages.
  2. I continued with the clean/rebuilt project anyway, just to be safe. When I turned the document baseline grid on, CPU usage shot up again, and the project became very sluggish, just like the old project. (I had been using document baseline grid in the old project as well.) The CPU and lag stick around; they don't just stop once it's finished aligning things (unless it's taking a very, very long time to do that). The CPU and lag persist if I delete the text from pages 5-400 so that almost every page is blank. It appears just having enough text frames and baseline grid enabled causes problems. If I turn the baseline grid back off, it becomes responsive again. (I checked this in both the new and old projects; both now behave this way.)

As a side note, I tried doing baseline grid via the text frames on a master page, and that setting doesn't seem to propagate to the pages that use that master. I have to do it individually (by editing detached) or by using the document baseline grid.

I'm also confused by text leading being ignored for the first line in a column. Maybe that's normal? But it makes it so I have to turn on the baseline grid to get things to line up, since I have headings that are different heights than the body text.

We have made fixes/improvements to this area (Text Frame Baseline Grid settings not inherited from a Master page text frame) of the program in the latest customer beta. If you would like to try these changes the beta software is available in the forum posts listed below.

The latest beta builds are downloadable from links at the top of each of these beta forum posts.

These betas install parallel, next to the release version (they do not overwrite your release) and so the fixes can be tried in the beta without affecting your normal workflow in the release version.

Once these programs have been through a full beta process the change will be released in a future free 1.8.0 update/patch to all customers.

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

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.