Does a glossary slow down PT or s/r?

Question

I've just been reading a thread about best practices for a glossary (https://support.bible/3952/glossary-best-practices). It's useful but raises a concern for me about how a glossary may afect PT's performance and s/r speed. It contains comments such as: "Good to know since large books in the peripherals really slow down Paratext...." and "The notes files became so big that this meant that send and receive became impossible, over fairly poor broadband. The reason for this ..."

PT is already painfully slow on my computer, especially when using Notes, so the above comments make me wary of starting a glossary. However, I see the thread I was reading is from 2018, so I'm asking if anything has changed with regard to this speed/performance issue and glossaries. Thanks.

Answer 1

After 5 years of better computers and some development on PT, the slowdown may not be as bad as it used to be.

But in general extremely long windows in PT slow it down. For example, if you opened the entire book of Exodus in a single view and started scrolling through, it might start lagging. That is particularly true for those of us using complex fonts which take extra computing power--it may be less noticeable if you're using a Latin script. This is part of the reason people almost always edit using "View-->Show all chapter" in its un-checked state.

With the glossary, that becomes a problem because the PT developers didn't create a method for breaking it up into chapters (and thus more manageable chunks). So by default turning off "View-->Show all chapters" doesn't help.

What I would suggest would be to start work on a glossary. Then, if you start to get slowdown, artificially split your glossary into chapters. Doing this will mean the linking with Biblical Terms stops working, so only use the chapter option if absolutely necessary.

Note that the slowdown only happens if that Glossary book happens to be open. It doesn't slow PT down across the board at all times.

-----------------

I just tested and, yes, the issue with flagged notes in the glossary is still a problem. I would call it a fairly major bug, personally.

When PT creates a flag, it saves some "context" of the surrounding words in order to place the flag in the right place. In regular books, that context is the verse. But since the glossary isn't broken into verses, it saves the entire chapter (which may be the entire glossary) each and every time you create a flag.

For example, our Glossary file is currently about 300kb long. That means that every time you create a new flag (or reply to a flag?), your Notes.xml file gets 300kb longer. You can see how that would add up quickly. (Breaking the glossary into chapters does make this problem less severe.)

In actual practice this doesn't cause us any problems. The team is likely only adding a few flags at a time, so each send/receive only uses one or two MB of data. But if we ever need to do a fresh S/R on a brand new project, it can take a while. One of the projects I'm involved with has 400+mb just of notes.

Answer 2

I have also found that long stretches of text in a single window can be very slow.

One other thing that is slow in the glossary: notes. Each note will (underlyingly, invisibly) append the whole contents of the current verse. If the glossary is not divided into verses, it will append the whole chapter, or (if the glossary is not divided into chapters) the whole glossary. After a few notes, it will be so slow as to be impossible to work with.

So if you need to collaborate on the glossary, either use a different system (I expect that a separate consultant notes project would not have this problem, though I haven't tried this with the glossary), or divide it into verses. This will have some additional complications when the glossary entries are linked to Biblical Terms, but there are workarounds for this (let me know if you'd like to know more).

Paulus

Answer 3

Thank you for your replies. It would seem then that it's best to either hold off starting a glossary or at least not to use the Notes feature in it.

Comments

It doesn't solve the large window problem, but we have solved the notes problem by creating verse numbers in our glossaries. We also solved a number of other problems with this method. We have a work-in-progress paper on it here: https://docs.google.com/document/d/1cdXeRc-Kj8wCYTTykc5KG6rSmjghFdq_nS6fAIVH_pk/edit#heading=h.33aihlqcr3zl.