После 5 лет использования более мощных компьютеров и некоторых разработок в PT замедление может быть не таким плохим, как раньше.
Но в целом очень длинные окна в PT замедляют его работу. Например, если вы откроете всю книгу Исход в одном представлении и начнете прокручивать, это может начать подтормаживать. Это особенно верно для тех из нас, кто использует сложные шрифты, требующие дополнительных вычислительных ресурсов, — это может быть менее заметно, если вы используете латиницу. Это одна из причин, по которой люди почти всегда редактируют, используя «View-->Show all chapter» в состоянии, когда он не отмечен.
С глоссарием это становится проблемой, потому что разработчики PT не создали метод для его разбивки на главы (а значит, и на более управляемые фрагменты). Поэтому по умолчанию отключение «View-->Show all chapters» не помогает.
Я бы предложил начать работу над глоссарием. Затем, если вы начнете замечать замедление, искусственно разделите ваш глоссарий на главы. Это означает, что связывание с Biblical Terms перестанет работать, поэтому используйте опцию глав только в том случае, если это абсолютно необходимо.
Обратите внимание, что замедление происходит только в том случае, если книга Глоссария открыта. Она не замедляет PT в целом постоянно.
-----------------
Я только что протестировал, и да, проблема с отмеченными заметками в глоссарии по-прежнему существует. Лично я назвал бы это довольно серьезным багом.
Когда PT создает флаг, он сохраняет некоторый «контекст» окружающих слов, чтобы разместить флаг в правильном месте. В обычных книгах этим контекстом является стих. Но поскольку глоссарий не разбит на стихи, он сохраняет всю главу (которая может быть всем глоссарием) каждый раз, когда вы создаете флаг.
Например, наш файл Глоссария в настоящее время имеет размер около 300 КБ. Это означает, что каждый раз, когда вы создаете новый флаг (или отвечаете на флаг?), ваш файл Notes.xml увеличивается на 300 КБ. Вы можете представить, как это быстро накапливается. (Разделение глоссария на главы делает эту проблему менее серьезной.)
На практике это не вызывает у нас никаких проблем. Команда, вероятно, добавляет только несколько флагов за раз, поэтому каждая отправка/получение использует только один или два МБ данных. Но если нам когда-нибудь понадобится выполнить новую S/R для совершенно нового проекта, это может занять некоторое время. В одном из проектов, в которых я участвую, только заметки занимают более 400 МБ.
