PT 8 is responding agonizingly slowly. Any suggestions?

Question

I am using PT8 on a Core i7 2.7 GHz laptop, 24 GB RAM and SSD drive, that is to say, it is a fast machine. Yet for some operations PT8 performs unbearably slowly.

Some examples:

To switch focus from the translation window to a search window can take as long as four seconds even without any other translations or windows open.
In PT 7.6 the same operation takes maybe 500 ms.

To open a Find window takes 5 seconds.
For the same operation in PT 7.6, perhaps 100ms.

Clicking on an item a list window and then shifting focus to the item in the text window takes up to 7 seconds.
For the same operation in PT 7.6, perhaps 1.5 sec.

I have Scroll scripture with compatible applications is turned off. Highlight current verse is turned off. I am using WIN 10. I was not using the Creators edition and it was like this. I then updated to the Creators edition, but he issue did not change. Currently I am on Insider Preview Build 16232.rs_prerelease.7064-1334, obviously with this same issue.

Is anyone else experiencing this? Any suggestions of what might be the matter?

Ancienne publication - affichée dans sa langue d'origine

Answer 1

BTW, on my own computer (Dell XPS-15, 7th gen Core i7 @ 2.8 GHz, 32 GB RAM, 1 TB SSD) it takes about 4 seconds to display a source-language lexicon window when I right click on a lemma in an SLT window, then choose from the lexicons offered.

Is that how long it is expected to take? on such a fast machine?

Ancienne publication - affichée dans sa langue d'origine

Comments

wdavidhj:

on my own computer (Dell XPS-15, 7th gen Core i7 @ 2.8 GHz, 32 GB RAM, 1 TB SSD)

On this same computer, as I write, PT8 has for some time been in a state where some operations take 30 secs–2minutes to complete:

• Entering a new marker into a footnote;
• Clicking with the mouse to mover the cursor to a different footnote (Standard view, with footnote panel displayed);
• Inserting text into a footnote with Ctrl+V;
• (Often) left or right cursor movements within a footnote;

Sorting the punctuation inventory by a different column is impossible: it just never happens.

The above are just some of the things I was needed to work on anyway, and tried as a test of what was slow.

While I’m waiting for PT to do what I asked of it, Windows Resource Monitor shows that PT is using 10–30% CPU. Sometimes the titlebar of the PT window says “Not responding”. Sometimes PT’s windows flash madly, and non-PT windows (e.g. a Word doc) end up on top of the PT window for a while (if a video of that would help, I can take one and upload it here).

Also, the cursor sometimes moves by itself to another place, resulting in text that I type or paste ending up in the wrong place.

I’m pretty sure restarting PT will fix this, but I’m still intrigued as to what’s going on. Any ideas from the developers?

Ancienne publication - affichée dans sa langue d'origine

---

My guess is that you have enough windows open that you are into memory management issues.

You may be wondering why you could be into memory problems when you have 32G of memory, but Paratext is a 32-bit application and is limited to what it can use. Theoretically it could use around 3G, but I’ve never seen it get much larger than 1G before it starts doing lots of memory management.

I think all the pieces are in place now that we could create a 64-bit version of Paratext, but this isn’t currently high on our priority list.

The first thing I recommend to users with performance problems is to do the following:

1. save a Text Combination for their current layout
2. close all except they main project window
3. restart Paratext
4. perform some of the actions that were slow to see how they work now
5. start opening more windows to see how that affects performance
   One tool that can help is Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer)

This is like Task Manager, but you can right-click on a process and then open Properties. One of the tabs will be “.Net Performance”. The most interesting counter there is “#Gen 2 Collections”. If that is increasing, that says Paratext is spending significant time doing memory management. Memory management is automatic by .Net, so the only thing we can do is to see if there is something being held in memory that should be released. There is another tool that can help find that.

John+Wickberg

Paratext Support

Ancienne publication - affichée dans sa langue d'origine

---

Thanks for a very helpful reply!

Yes, Windows Resource Monitor shows for Paratext, in the Private Bytes column, a figure that’s hovering around 1 GB.

I have 21 windows open within the main window, plus the Punctuation Inventory window, and four Changes Sent and Received windows that I hadn’t closed. So that’s a lot – I hadn’t realised that it would hit a limit, but I understand the 32-bit issue.

I’m intrigued by two things:

• Would it be possible for PT to handle this more gracefully, i.e. tell the user that memory is short, and that they should close some windows;
• My total windows listed above is 26. Let’s assume (very crudely) that the PT program needs 0.5 GB. That would mean that each window is taking 40 MB on average. Does a window really need that much memory?

Ancienne publication - affichée dans sa langue d'origine

---

It’s hard to give a estimate for how much memory a window would use - depends a lot on the type of window.

For the standard text window, it also depends on how many notes there are in the project since all notes are loaded. If “Spelling status” is enabled, the word list has to be loaded. If Biblical Term highlighting is enabled, that data needs to be loaded.

We also cache some information, so if you go from place to place, more memory will be used.

Other windows will normally cause other data to be loaded and the size of this will vary.

We anon421222’t do memory investigations until a problem is noticed - like Paratext keeps getting bigger as some action is done. This can mean we are holding on to something that should be freed.

As for trying to handle it more gracefully, we haven’t considered doing anything like that. It would be hard to know when to draw a limit - memory can go up high briefly, but go down again later. Allowing .Net to handle this is our main strategy and we just have to find places where a mistake in the code is causing us to hold onto too much.

John+Wickberg

Ancienne publication - affichée dans sa langue d'origine

Answer 2

If you still have the PT instance

(Shift) Help -> Advanced -> View Memory Status

Click Measure, to display an internal memory report.
“Measure and save…” will save the details to file.

There is also a “Free memory” option section:
It would be interesting to know if clicking on those 3 buttons (maybe twice each) and then clicking on Measure again made any significant difference.

Ancienne publication - affichée dans sa langue d'origine