Невыносимо медленная работа с большими проектами в PM

[workoles]

Привет! Уже давно порываюсь создать тему на данную тему, но всё время откладываю в основном по причине ясности ответа со стороны разработчиков, но тем не менее попытка не пытка...)

У PM есть одно слабое место - крайне медленная работа с проектами, где количество кубиков от нескольких тысяч. И чем шире становится проект, тем сложнее с ним становится работать. Копирование/вставка экшенов занимает уже не считаные секунды, а 20-30-60 и более секунд (всё зависит от количества экшенов и связей). Скроллинг превращается в пытку, особенно в тех местах проекта, где связей больше, чем в среднем по проекту...

И по сути я знаю самый верный способ оптимизации - писать на голом C#, но в таком случае ProjectMaker будет мало чем отличаться от того же Visual Studio. А ведь экономия времени - это основная фича ZP, ради которой я предпочитаю именно его.

Само собой я умею оптимизировать многие внепроектные аспекты, использовать вложенные проекты, могу переложить многие экшены на C#, в своё время до дыр зачитал официальную справку и статьи, подобные этим:

1. http://zennolab.com/discussion/threads/bazovye-ponjatija-optimizacii-shablonov.12606/
2. http://zennolab.com/discussion/threads/xvatit-ehto-terpet-optimiziruj-shablon-zenno-pk-uvelich-proizvoditelnost-zadach.27708/#post-195567

Они хороши, но на больших проектах, к сожалению, беспомощны, т.к. речь идёт не о выполнении готовых проектов, а об их создании в PM.

Также хочу отметить, что железо у меня не самое слабое, да и ускоряться за счёт наращивания мощностей, как мне кажется, путь тупиковый - это лишь оттягивание безысходного. Словом, этой записью я всего лишь хочу обратить внимание разработчиков на данную проблему и придумать реальные пути увеличения визуального быстродействия. Даже если вы скажете, что для этого необходимо будет работать в режима 256 цветов и отключенным каким бы то ни было визуальным оформлением. Я согласен!)

 

[ZennoScript]

Согласен.
У самого имеется несколько достаточно крупных проектов, которые часто приходится редактировать.
Ожидание того, пока вставится какой-то элемент не вызывает радости. А если, случайно, нажмёшь отмену действия, вспоминаешь, почему нельзя этого делать..

 

[VladZen]

Пришлите нам пожалуйста пример такого проекта. Мы посмотрим проблему.

 

[workoles]

Пришлите нам пожалуйста пример такого проекта. Мы посмотрим проблему.

Для воспроизведения всего вышеописанного можете просто мультиплицировать любой существующий проект. Возьмите любой шаблон на несколько сот кубиков (если есть свичи, то прекрасно, они те ещё пожиратели времени) и скопируйте его раз 10-50 внутри этого же проекта. Количество раз будет зависеть от размера проекта донора и мощности конкретно вашей машины, но 100% рано или поздно вы упрётесь в потолок, после которого даже очередная вставка будет выполняться в разы дольше, чем изначально. После этого попробуйте произвести самые рядовые операции: выделить часть проекта лассо, отменить действие, вставить новый экшен, проскроллить проект, перейти в режим расширенного редактирования и открыть окно со свойствами действия и т.п. Уверен, вы сразу всё поймете)

 

[ZennoScript]

Пришлите нам пожалуйста пример такого проекта. Мы посмотрим проблему.

Проект начинает виснуть тогда, когда его размер переваливает за 2 мб. После этого уже зависит от Вашей тачки.

 

[VladZen]

Для воспроизведения всего вышеописанного можете просто мультиплицировать любой существующий проект. Возьмите любой шаблон на несколько сот кубиков (если есть свичи, то прекрасно, они те ещё пожиратели времени) и скопируйте его раз 10-50 внутри этого же проекта. Количество раз будет зависеть от размера проекта донора и мощности конкретно вашей машины, но 100% рано или поздно вы упрётесь в потолок, после которого даже очередная вставка будет выполняться в разы дольше, чем изначально. После этого попробуйте произвести самые рядовые операции: выделить часть проекта лассо, отменить действие, вставить новый экшен, проскроллить проект, перейти в режим расширенного редактирования и открыть окно со свойствами действия и т.п. Уверен, вы сразу всё поймете)

Проект начинает виснуть тогда, когда его размер переваливает за 2 мб. После этого уже зависит от Вашей тачки.

Это логично, что для больших проектов, нужно и мощное железо.
Какое железо и ОС у вас, и какие все-таки кубики используются в проекте? Не работает ли проект с большими списками/таблицами.

 

[ZennoScript]

Вот комп:

единственное, что видика нет (вернее он в проце), может быть конечно и от этого тормозит.

Шаблон вот такого вида:

Весит он 3,6 мб. Работать с этим шаблоном - одно удовольствие.

Что значит больших списков\таблиц? Файлы могут быть большими, но тормоза идут не при отладке, а при написании шаблона. Т.е. именно что то там скопировать\вставить - занимает секунд 10 минимум.

 

[VladZen]

Что значит больших списков\таблиц? Файлы могут быть большими, но тормоза идут не при отладке, а при написании шаблона. Т.е. именно что то там скопировать\вставить - занимает секунд 10 минимум.

Именно, которые привязаны к большим файлам, например txt спискам на несколько МБ.

 

[ZennoScript]

Именно, которые привязаны к большим файлам, например txt спискам на несколько МБ.

Вот в текущий момент там все файлы по несколько кб. Так что проблема явно не в них.

 

[workoles]

Для максимального понимания сделал запись экрана в реальном времени. Проект предварительно не стартовался (перед записью лишь заранее открыл шаблон в PM), т.е. никаких привязок ни к спискам ни к таблицам не производилось, т.е.

Не работает ли проект с большими списками/таблицами.

нет, не работает. Исключительно свежеоткрытый проект. Но на всякий случай уточню, что самый тяжёлый список на момент записи 726KB.

Итак, в видео последовательно демонстрируется работа лассо, масштабирование, копирование/вставка/удаление экшена, отмена действия. Весь этот нехитрый набор из 6 операций занял 6 мин 36 сек. Итак:

Подытожим:

• Копирование/вставка — 14 сек.
• Удаление — 13 сек.
• Отмена действия — 68 сек.
• Выделение части проекта лассо — 173 сек. (не самый объективный параметр, но выделять куски проекта на практике тоже приходится )
• Отмена выделения — 8 сек.

Само собой, если производить операции не с одним экшеном, а сразу с группой, то время отклика увеличится ещё секунд на 5-10, а если запустить проект и поработать с ним какое-то время, то все тайминги увеличатся ещё минимум в 2-3 раза и работа превратится в тот ещё мазохизм Так, чтобы добавить в проект 10 экшенов, потребуется в районе 5 минут чистого ожидания.

Так же на видео можно заметить, что при использовании лассо, визуальная часть начинает несоразмерно сильно подвисать в момент прохождения курсора над графическими элементами, хотя по сути команда на само выделение ещё не была отправлена.

Какое железо и ОС у вас

Все операции производились на такой конфигурации:

Графика: NVIDIA GeForce GT 330M 1024 MB
Жёсткий диск: SSD 128GB

какие все-таки кубики используются в проекте?

Кубики разнообразные. Много свичей, логики и операций с текстом/списками. В общем-то на видео видно большинство типов.

P.S.
В ZP проект работает прекрасно, а вот в плане разработки беда.

P.S.S.
Забыл ещё показать скроллинг, который в общем-то больше напоминает слайдшоу, нежели хорошую навигацию.

 

[ZennoScript]

Для максимального понимания сделал запись экрана в реальном времени. Проект предварительно не стартовался (перед записью лишь заранее открыл шаблон в PM), т.е. никаких привязок ни к спискам ни к таблицам не производилось, т.е.

нет, не работает. Исключительно свежеоткрытый проект. Но на всякий случай уточню, что самый тяжёлый список на момент записи 726KB.

Итак, в видео последовательно демонстрируется работа лассо, масштабирование, копирование/вставка/удаление экшена, отмена действия. Весь этот нехитрый набор из 6 операций занял 6 мин 36 сек. Итак:

Подытожим:

• Копирование/вставка — 14 сек.
• Удаление — 13 сек.
• Отмена действия — 68 сек.
• Выделение части проекта лассо — 173 сек. (не самый объективный параметр, но выделять куски проекта на практике тоже приходится )
• Отмена выделения — 8 сек.

Само собой, если производить операции не с одним экшеном, а сразу с группой, то время отклика увеличится ещё секунд на 5-10, а если запустить проект и поработать с ним какое-то время, то все тайминги увеличатся ещё минимум в 2-3 раза и работа превратится в тот ещё мазохизм Так, чтобы добавить в проект 10 экшенов, потребуется в районе 5 минут чистого ожидания.

Так же на видео можно заметить, что при использовании лассо, визуальная часть начинает несоразмерно сильно подвисать в момент прохождения курсора над графическими элементами, хотя по сути команда на само выделение ещё не была отправлена.


Все операции производились на такой конфигурации:

Графика: NVIDIA GeForce GT 330M 1024 MB
Жёсткий диск: SSD 128GB

Кубики разнообразные. Много свичей, логики и операций с текстом/списками. В общем-то на видео видно большинство типов.

P.S.
В ZP проект работает прекрасно, а вот в плане разработки беда.

P.S.S.
Забыл ещё показать скроллинг, который в общем-то больше напоминает слайдшоу, нежели хорошую навигацию.

Ого у тебя там петрушка наворочена )

 

[VladZen]

Будем тестировать. Пример, проекта конечно сильно бы облегчил задачу.
Все-таки больше грешу на списки и таблицы, т.к. более-менее знаю внутренности программы и что может влиять, как вижу в обоих примерах они используются в проектах. Поэтому прошу снять вот эту настройку (если включена) и проверить быстродействие.

 

[workoles]

Поэтому прошу снять вот эту настройку (если включена) и проверить быстродействие.

Посмотреть вложение 24607

В PM 5.11.3.0 такой настройки нет. Но попробовал проверить гипотезу со списками/таблицами и удалил вообще все доп. блоки: списки, таблицы, входные настройки и даже блок шифрования:

К сожалению, абсолютно ничего не изменилось. Да, кстати, операция удаления списка/таблицы занимает всё те же 14 сек.

Чисто интуитивно могу умозаключить, что на скорость реакции интерфейса влияет именно количество экшенов в проекте. Складывается ощущение, что при каждой операции PM просчитывает весь проект целиком, а не лишь тот участок/действие, с которым я работаю.

 

[ZennoScript]

Я так замечал, что большие свитчи и большое количество ифов сильно влияет на скорость обработки.
Порой 1 свитч полностью убивает возможность дальнейшего редактирования шаблона, в связи с чем стараюсь их вообще не использовать. Только в самых крайних случаях.

 

[workoles]

Я так замечал, что большие свитчи и большое количество ифов сильно влияет на скорость обработки.
Порой 1 свитч полностью убивает возможность дальнейшего редактирования шаблона, в связи с чем стараюсь их вообще не использовать. Только в самых крайних случаях.

Согласен насчёт свитчей. Сам неоднократно замечал, что при их разрастании быстродействие замедляется, а сами свитчи иногда даже просто пропадают, т.е., например, есть свитч с двадцатью вариантами действий и в какой-то момент все варианты просто пропадают и остаётся один дефолтный вариант. При этом иногда спасает 1 отмена действия, а иногда требуется 2,3-5 и более отмен. Т.е. для того, чтобы вернуть всё как было, требуется 5-10 минут времени. Тем не менее протестировал этот момент, удалил абсолютно все свитчи из шаблона (а потом ещё и все списки и таблицы), но это не решило ситуацию.

 

[VladZen]

В PM 5.11.3.0 такой настройки нет. Но попробовал проверить гипотезу со списками/таблицами и удалил вообще все доп. блоки: списки, таблицы, входные настройки и даже блок шифрования:

К сожалению, абсолютно ничего не изменилось. Да, кстати, операция удаления списка/таблицы занимает всё те же 14 сек.

Чисто интуитивно могу умозаключить, что на скорость реакции интерфейса влияет именно количество экшенов в проекте. Складывается ощущение, что при каждой операции PM просчитывает весь проект целиком, а не лишь тот участок/действие, с которым я работаю.

Я могу сказать, что после версии 5.11.3.0. уже были оптимизации по работе интерфейса PM.

 

[Gfoblin]

Напомнило:

Запихнуть все подобные действия хотябы в подпроекты не пробовали?
Я не знаю как писали сам PM, но боюсь просто на рендеринг этой вот всей темы уходит очень много процессорного времени, а процик у вас откровенно старенький и слабенький....

 

[workoles]

Я могу сказать, что после версии 5.11.3.0. уже были оптимизации по работе интерфейса PM.

Попробую обновиться. Хотя есть у меня сильное предчувствие, что проблему это не решит, потому как скорее всего истина где-то рядом:

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

Скорее всего так и есть. Тем не менее, если данная конфигурация ПК слабовата для обработки визуалки РМ, то это точно не есть хорошо. Я тоже не знаю как написан РМ, но уверен, что это лечится) Думаю, как минимум можно отрисовывать, например, только то, что находится на экране, а не весь проект целиком (хотя бы опционально).

Запихнуть все подобные действия хотябы в подпроекты не пробовали?

Пробовал. Но запихнуть в подпроект можно только самостоятельный участок, который имеет четкое начало и конец (т.е., если дочерний шаблон может во множестве мест вернуться к материнскому, то в материнском необходимо предусмотреть все эти исходы, а это сложно назвать оптимизацией). А конкретно в этом проекте таких участков у меня не много. Ну или придется нарезать шаблон очень мелко, а за это покупателю зеннобокса придется раскошелиться.

 

[ZennoScript]

Поменьше гибких линий...Пусть будет немного убого выглядеть, но при написании первостепенно удобство и комфорт. Визуализация уже во вторую очередь, как по мне..
Т.е. максимально упростить графику, это могло бы упростить обработку больших шаблонов.

 

[workoles]

Обновился до последней версии 5.12.2.0 и вынес ZP на выделенный (dedicated) сервер с такими характеристиками:

CPU: описание
Жёсткий диск: SSD 128GB
Видеочип: интегрированный

Повторил все вышеописанные в видео процедуры с тем же шаблоном. Итого:

• Копирование/вставка — 5 сек. (-9 сек.)
• Удаление — 4 сек. (-9 сек.)
• Отмена действия — 20 сек. (-48 сек.)
• Выделение части проекта лассо — 15 сек. (-158 сек.)
• Отмена выделения — 2 сек. (-6 сек.)

В среднем быстродействие увеличилось примерно в 2,5-3 раза. По ощущениям на сервере работать немного комфортнее. Большой минус в том, что не удобно работать с двумя мониторами и в том, что держать отдельный сервер под PM — слегка кошерное мероприятие)

Ну и подведу заключительный итог (коль уж выделил время и заставил себя создать тему и провести всю эту гору тестов). На данный момент у меня сложилось вполне однозначное понимание того, что PM нуждается в серьёзной доработке в области быстродействия. На скорость работы сильно влияет количество кубиков и связей между ними внутри проекта. Работать с проектами более 2МБ на среднестатистическом железе весьма затратное по времени мероприятие. Планируйте логику и оптимизируйте большие проекты ещё до старта разработки, изучайте C# и используйте подпроекты. Пока только так, но это совершенно не значит, что разработчикам можно использовать это как оправдание и ничего не делать в этом направлении! Необходимо иметь ввиду, что подпроекты не всегда могут придти на помощь, а использование голого C# начисто убивает все преимущества ZP. Поэтому считаю, что задача оптимизации работы PM должна стать одной из основных в обозримом будущем. Спасибо, что прочитали!

 

[zortexx]

Рамдиск используете?

 

[workoles]

Рамдиск используете?

Нет, но, кстати, да) Спасибо за совет. Сейчас попробую ещё в этом направлении покопать. А вы используете? Есть прирост при работе с ZP/PM?

 

[zortexx]

Ответил в ЛС.

 

[workoles]

@VladZen
Сделал видео в режиме реального времени как очень легко повторить резкое снижение производительности PM (на любом проекте).

Все пояснения делал по ходу записи в блокноте, но на всякий случай вынесу сюда основное. Цель видео — показать как снижается производительность интерфейса PM при увеличении количества экшенов с 22 до 5 500 шт. (файл проекта на 5 МБ). В видео делается простая и одна из самых часто используемых операций — копирование/вставка экшена, которая в итоге длится порядка 20 сек(!!). За основу взят стандартный проект из набора PM «2. Form filling registration.xmlz», состоящий из 22 экшенов. Список в проекте всего один, стрелок минимум (всего 250 шт.), логика и свитчи отсутствуют. Уделите, пожалуйста, 10 минут своего времени для ознакомления с проблемой. Да, это много, но работать приходится в ещё более суровых реалиях Спасибо!

 

[VladZen]

@VladZen
Сделал видео в режиме реального времени как очень легко повторить резкое снижение производительности PM (на любом проекте).

Все пояснения делал по ходу записи в блокноте, но на всякий случай вынесу сюда основное. Цель видео — показать как снижается производительность интерфейса PM при увеличении количества экшенов с 22 до 5 500 шт. (файл проекта на 5 МБ). В видео делается простая и одна из самых часто используемых операций — копирование/вставка экшена, которая в итоге длится порядка 20 сек(!!). За основу взят стандартный проект из набора PM «2. Form filling registration.xmlz», состоящий из 22 экшенов. Список в проекте всего один, стрелок минимум (всего 250 шт.), логика и свитчи отсутствуют. Уделите, пожалуйста, 10 минут своего времени для ознакомления с проблемой. Да, это много, но работать приходится в ещё более суровых реалиях Спасибо!

Прище было бы, если бы вы просто прислали проект, на котором воспроизводится проблема.

 

[workoles]

Прище было бы, если бы вы просто прислали проект, на котором воспроизводится проблема.

Загрузил в облако — https://cloud.mail.ru/public/FChM/eudt8texr
Это файл, который получился в видео выше. Попробуйте скопировать / вставить экшен, выделить и удалить группу на пару сотен экшенов.
Железо из этого поста - http://zennolab.com/discussion/threads/nevynosimo-medlennaja-rabota-s-bolshimi-proektami-v-pm.43284/#post-321033

 

[VladZen]

Загрузил в облако — https://cloud.mail.ru/public/FChM/eudt8texr
Это файл, который получился в видео выше. Попробуйте скопировать / вставить экшен, выделить и удалить группу на пару сотен экшенов.
Железо из этого поста - http://zennolab.com/discussion/threads/nevynosimo-medlennaja-rabota-s-bolshimi-proektami-v-pm.43284/#post-321033

Спасибо за наглядный пример. Передал программистам, постараются оптимизировать отзывчивость интерфейса в след. версиях программы.

 

[RoyalBank]

Заметил следующее.
C# "не любит" когда в него (кубик) переносят большой spintax текст для обработки. Прирост тормозов просто впечатляет.
Результаты скорости открытия проекта в PM в секундах:
Кубики со спинтаксом ~ 5.5 секунд;
Спинтакс из кубиков перенесен в C# ~ 50 секунд; - прирост x10
Спинтакс из C# вынесен в ownCode ~ 5 секунд. - При этом, сам PM, работает без подлагов.

Условия везде одинаковые, только меняется подход для обработки спинтакса.

Спойлер: Конфигурация компьютера

Win10
Cpu: i7-6700k
Ram: 32 Gb
Ssd: Samsung 850 Pro
Gpu: Gigabyte 1060 Extreme

 

[Dimionix]

C# "не любит" когда в него (кубик) переносят большой spintax текст для обработки. Прирост тормозов просто впечатляет.

А зачем в него вообще толкать этот spintax?
Держите его в .txt файле, а в коде подгружайте.
Если же не хотите палить свой spintax, то перед кубиком "C# код" добавьте кубик "Обработка текста - В переменную", в котором пропишите spintax, а в коде получайте значение из переменной.
В файле, кстати, можно данные держать и в зашифрованном виде, а в коде расшифровывать.

 

[RoyalBank]

Если же не хотите палить свой spintax, то перед кубиком "C# код" добавьте кубик "Обработка текста - В переменную", в котором пропишите spintax, а в коде получайте значение из переменной.

Этот метод, как раз соответствует значению в 5.5 секунд из первого результата.

А зачем в него вообще толкать этот spintax?

Ну тут такое, когда написал весь проект на C#, заметил, что пошли тормоза жесткие в шаблоне из PM, начал искать, обнаружил, что спинтакс.
Дальше пришел к переносу в ownCode, собственно результат в 5 секунд, против 50, меня полностью устроил.