MasterSCADA 4D 1.3.1 - Где обещанное быстродействие редактора проектов?

[b_aleks2]

В случае Firebird действительно так. Из 6 минут процесса компиляции 4:30 заняла загрузка элементов из БД (грузится все кроме кешированных окон).
Провел аналогичный тест после конвертации этого проекта в Postgre - https://www.screencast.com/t/ElWJztcAD
Весь процесс компиляции - 1:17, из этого этап загрузки элементов всего 15 сек. Даже если суммарно смотреть от старта приложения по конца компиляции 1:50, в случае Firebird - 6:43

Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - это видео запишу позже, там тоже ускорение относительно Firebird. По работе с Postgre были сделаны некоторые оптимизации, которые пока в версии 1.3.2 Beta. На следующей неделе должны попасть в 1.3.1. Доработки по Firebird, о которых говорил ранее, включены в 1.3.1.31444(MPLCD_1_3_20230314.1)

Как говорил ранее, в Postgre был принципиально изменен механизм, вместо отдельного потока работы с БД, запросы чтения идут синхронно из запрашивающего потока. В этом режиме пришлось отказаться от некоторых оптимизаций на уровне БД, которые неприменимы в многопоточной среде, поэтому отдельные сценарии могли быть даже медленнее, чем в Firebird. Но за счет возможности распараллеливать процессы компиляции и большей скорости работы БД основные сценарии сильно ускорились.

Так, я все-таки сконвертировал проект в Postgre. Ну что я могу сказать. 25 минут конвертации - это жесть, при этом все также два ядра из восьми нагружены MS4D, в то время как Postgree пашет на всех ядрах (на скрине это видно). После конвертации еще 20 минут ждал, пока проект закрывался, разрастаясь до 20 ГБ в ОЗУ.
Закрытие проекта.png Производительность.png Подробности.png
Да. То, о чем Вы пишете - экспорт проекта, теперь происходит за полторы минуты. Но и тут такая же ситуация с нагрузкой - MS4D грузит два ядра, Postgre грузит все восемь.
Теперь, что касается других моментов. Если сравнивать мой проект на Firebird с этим же проектом на Postgre, то я не заметил никакой разницы в скорости других операций:
проверку целостности проекта я вообще не смог сделать (ждал 20 минут);
большие окна, где выведены все вложенные объекты, открываются по несколько минут;
мнемосхемы объектов открываются по ~10 секунд;
программы периодически компилируются по ~10 секунд;
деревья раскрываются по несколько секунд;
все вышеописанные операции сопровождаются зависаниями и периодическими "Не отвечает"

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

Также я замечу, что в процессе компиляции проекта у меня пару раз появлялись рандомные ошибки, которые пропадали после переоткрытия проекта. Также один раз после открытия проекта не подгрузилось дерево одного вложенного объекта, что также дало ошибки при компиляции. Ниже дам ссылку на длинное видео, где показывается все вышеописанное - ошибки компиляции, неподгруженное дерево объекта, зависания и медленная работа проекта.
https://dropmefiles.com/4vuuw

P.S. Вы так и не ответили на главный вопрос. Почему всегда грузятся два ядра в большинстве операций? В таком случае, те рекомендуемые системные требования, которые описаны в справке, не имеют никакого смысла, ведь ПК просто простаивает.

P.S. 2. Сделайте, чтобы при создании БД в Postgre ей сразу давалось нормальное название. А не "ms4d_project_2", в то время как этот проект в редакторе имеет осмысленное название.

[Виктор Момотов]

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

Также я замечу, что в процессе компиляции проекта у меня пару раз появлялись рандомные ошибки, которые пропадали после переоткрытия проекта. Также один раз после открытия проекта не подгрузилось дерево одного вложенного объекта, что также дало ошибки при компиляции. Ниже дам ссылку на длинное видео, где показывается все вышеописанное - ошибки компиляции, неподгруженное дерево объекта, зависания и медленная работа проекта.
https://dropmefiles.com/4vuuw

P.S. Вы так и не ответили на главный вопрос. Почему всегда грузятся два ядра в большинстве операций? В таком случае, те рекомендуемые системные требования, которые описаны в справке, не имеют никакого смысла, ведь ПК просто простаивает.

На какой версии вы проверяли? На видео 1.3, но оптимизации по Postgre, как писал выше, пока только в сегодняшней бета версии. Так же в ней исправлены некоторые ошибки с многопоточной компиляцией.
Скорость открытия окон посмотрим также, но там могут быть уже тормоза из-за визуализации WPF а не БД.
По распараллеливанию процесса компиляции и загрузки проекта в Postgre еще есть идеи, как доработать. В ближайшее время постараемся сделать.

большие окна, где выведены все вложенные объекты, открываются по несколько минут;

Какое именно окно открывали? На видео не увидел.

[b_aleks2]

На какой версии вы проверяли?

Версия: 1.3.1.31444(MPLCD_1_3_20230314.1)

Какое именно окно открывали? На видео не увидел.

2023-03-16_12-34-23.png

Скорость открытия окон посмотрим также, но там могут быть уже тормоза из-за визуализации WPF а не БД.

Тормозят не только окна, но и программы, раскрытие деревьев и прочее. Смысл одни окна править, если наверняка это какая-то общая проблема, что весь редактор какой-то неповоротливый.

[Виктор Момотов]

Да. То, о чем Вы пишете - экспорт проекта, теперь происходит за полторы минуты. Но и тут такая же ситуация с нагрузкой - MS4D грузит два ядра, Postgre грузит все восемь.

После некоторых доработок Postgre провел новые тесты на бета версии 1.3.2 -
1. Компиляция после открытия проекта и сброса кеша - 3:03 https://www.screencast.com/t/j6Qb6bbA (начиная с этапа компиляции мнемосхем видно, что загружены все ядра, но в начале компиляции 1 минуту идет запрос элементов, пока это не параллелится, но попробуем в этом сценарии это также доработать)
2. Компиляция после открытия проекта - 1:08 https://www.screencast.com/t/FM1aAyS5PVBF

В сравнении аналогичные тесты на Firebird на этой же версии
1. Компиляция после открытия проекта и сброса кеша - 5:54 https://www.screencast.com/t/vxn2GC6B3dp
2. Компиляция после открытия проекта - 4:37 https://www.screencast.com/t/iIAzOZVp6
Ранее было 13:25 и 5:48 (https://owen.ru/forum/showthread.php...l=1#post403180)
То есть доработки по параллельной компиляции окон также ускорили сценарий пересоздания кеша окон Firebird более чем в 2 раза.

большие окна, где выведены все вложенные объекты, открываются по несколько минут;
мнемосхемы объектов открываются по ~10 секунд;
программы периодически компилируются по ~10 секунд;
деревья раскрываются по несколько секунд;

Действительно в Postgre были неоптимальные запросы загрузки элементов по ссылкам из программ/окон. Поправили это, теперь выглядит так
https://www.screencast.com/t/geCfzz2JThU

Часть изменений будет перенесено в 1.3.1 на следующей неделе. Некоторые оптимизации скорее всего выйдут в рамках 1.3.2 в конце апреля.

[b_aleks2]

То есть доработки по параллельной компиляции окон также ускорили сценарий пересоздания кэша окон Firebird более чем в 2 раза.

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

Действительно в Postgre были неоптимальные запросы загрузки элементов по ссылкам из программ/окон. Поправили это, теперь выглядит так
https://www.screencast.com/t/geCfzz2JThU

Не совсем заметил разницу. Программы FBD также компилируются более чем 20 секунд (в Postgre вообще было полторы минуты), "тяжелые" окна по четыре минуты (почти две минуты в случае Postgree), окно узла открывается по две минуты (40 секунд в случае Postgre).
Видео с навигацией в проекте с Firebird: https://disk.yandex.ru/i/6u4braa0CNabfQ
Тоже самое, но с Postgre: https://disk.yandex.ru/i/b8ZYHi4FYAFQhQ

Также во время конвертации проекта и обновления библиотек загружены два ядра:
https://disk.yandex.ru/i/AxQGh4m1xj6piA
Как мне кажется, если загрузить все ядра, то может быть эти операции будут осуществляться быстрее. Это я к тому, что есть над чем работать. То есть сейчас, как мне кажется, оптимизирован только процесс компиляции проекта, а остальные операции - не очень.