[ID CC-CC2022] Торможение при выделении объемных текстов

  • Автор темы Автор темы -IKS-
  • Дата начала Дата начала
I

-IKS-

Топикстартер
15 лет на форуме
Сообщения
208
Реакции
2
Привет!
Иногда приходится работать со специфическии объемными книгами - просто голый текст, без изображений, без таблиц, редкие подзаголовки, но важный момент - весь текст залит одним длинным взаимосвязанным фреймом.

Заметил, что зависимость обработки этого текста от объема прямо чуть ли не экспоненциальна.
Если элементарное выделение (Ctrl-A) на 100-страничном текст - это секунда-две, на 200- страничном - секунд 10, то выделение 1000-страничного текста - может занимать до 10 минут.
Такая же история с заменой FindChangeByList-ом. На 1000 страничных текстах можно на полчаса уходить "курить", хотя 100-страничный обрабатывается за 5-10 секунд.

Причем даже не важно - разлит ли текст уже по полосам, или еще пока нет.

Разбить публикацию на куски и обрабатывать кусками очень неудобно, т.к. над всем текстом производится масса замен, в т.ч. и ручных, которые неудобно делать поглавно.

Отключение префлайта, проверки орфографии, включение построчного компоновщика абзацев на проблему почти не влияют.

Где бы еще копнуть?

p.s. Что интересно, до индизайна CS6 включительно подобных тормозов не было, а на всех CC, включая актуальную версию, уже тормозит. До CC мы спокойно обрабатывали даже 2500-страничные публикации за раз, без тормозов и на гораздо более слабых компьютерах.
 
И еще заметил особенность - если текст не выделять Ctrl-A, то тот же FindChangeByList отрабатывает достаточно быстро. Т.е. проблема в первую очередь именно при выделении текста. А у меня некоторые скрипты как только по выделенному умеют работать.
 
Elsynor сказал(а):
Это же 15+ см в корешке':=)'…
Нажмите, чтобы раскрыть...
Те, что по 2500, не совсем книги, а вот такие штуки. До 13 см в корешке. Сейчас эти сборники мы уже не выпускаем, но комментарии к законодательству по 800-1000 страниц попадаютися часто.
photosdz.jpg
 
Такие объемы текста, действительно будут обрабатываться довольно долго
 
@LeonidB, Лёня))) где ты такую хрень берёшь?

4. Используйте утилиту управления шрифтами (например, ATM Deluxe), чтобы минимизировать число активных шрифтов в системе.
 
Любимцев сказал(а):
Такие объемы текста, действительно будут обрабатываться довольно долго
Нажмите, чтобы раскрыть...
Я не понимаю другого. Почему скорость обработки не пропорциональна объему? При увеличении объема в 10 раз скорость выделения замедляется в 100.
И почему до CS6 проблем с выделением не было, а в почти таком же CC2014 эта проблема резко вылезла и до CC2018 так и не исправлена.
 
-IKS- сказал(а):
Я не понимаю другого. Почему скорость обработки не пропорциональна объему? При увеличении объема в 10 раз скорость выделения замедляется в 100.
И почему до CS6 проблем с выделением не было, а в почти таком же CC2014 эта проблема резко вылезла и до CC2018 так и не исправлена.
Нажмите, чтобы раскрыть...
Суть вашего вопроса - вам интересна причина, по которой зависимость скорее, квадратичная, чем линейная? Все поддается обьясненью и все нуждается в земле. Дело в том, что все обьекты взаимодействуют друг с другом, соответственно, корректно при каждом изменении макета (даже таком безобидном, как выделение текста) должны перебираться все пбьекты со всеми, т.е. хорошо уже, что зависимость хотя бы квадратическая, а не экспоненциальная или факториальная. Но попробуем пованговать, почему, таки, именно квадратичная? Предположим, что алгоритм оптимизирован настолько, что просчитываются только попарные сочетания обьектов по одному разу (хотя, с точки зрения программирования, это утопия, к которой следует стремиться) Легко видеть, что данное количество операций имеет порядок именно второй степени от общего количества обьектов. Что и требовалось доказать.
 
Это еще хоть как-то объяснимо при обработке, если алгоритм совсем не оптимизирован. Но при простом выделении какие-такие операции производит индизайн?
И почему оно сломалось именно в в CC?
 
А если попробовать отключиться на время от интернета/локальной сети? Просто перебираю варианты... :)
 
-IKS- сказал(а):
Это еще хоть как-то объяснимо при обработке, если алгоритм совсем не оптимизирован.
Нажмите, чтобы раскрыть...
Внимательно читайте
_MBK_ сказал(а):
Предположим, что алгоритм оптимизирован настолько, что просчитываются только попарные сочетания обьектов по одному разу (хотя, с точки зрения программирования, это утопия, к которой следует стремиться)
Нажмите, чтобы раскрыть...
Т.е. это, как раз, наоборот, самый идеально оптимизированный случай, в реале же должна быть
_MBK_ сказал(а):
экспоненциальная или факториальная
Нажмите, чтобы раскрыть...
-IKS- сказал(а):
И почему оно сломалось именно в в CC?
Нажмите, чтобы раскрыть...
На самом деле так было всегда, просто новые версии по определению более тормозные и требовательные к ресурсам - иначе кто будет новое железо покупать? Рубить сук на котором сидит никто не желает
 
Сейчас попробовал отключиться, вторую минуту висит...

зы. Это я про интернет
 
_MBK_ сказал(а):
новые версии по определению более тормозные и требовательные к ресурсам
Нажмите, чтобы раскрыть...
Как-то слишком выборочное тормозное место получилось. По остальным функциям такого катастрофического падения производительности нет.
Я убежден на 100%, что это ошибка.
Что происходит в момент выделения? - Запоминаются позиции начала и конца. Что там можно минутами делать?
 
LeonidB, ситуация я думаю воспроизводима на любом компе. Просто создайте файл на 1000 страниц и залейте любым голым текстом.
Далее, ставим текстовый курсор в текст и жмем Ctrl-A и наслаждаемся ожиданием....
 
Для ответа нужно войти/зарегистрироваться
Верх Низ