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

[b_aleks]

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

Тогда я не совсем понимаю, почему должна повысится производительность и скорость работы редактора проектов. Что тогда подразумевают Ваши сотрудники, когда на своих вебинарах заявляют, что в версии 1.3.1 решены проблемы быстродействия и ресурсоемкости редактора проектов?
То есть Firebird и так был медленным по причине однопоточности чтения и записи, но Вы решили еще где-то сбоку нагородить взаимодействие с Postgree, которое, по Вашим же словам, даст выигрыш только в НЕКОТОРЫХ проектах. Пока что это выглядит, как flex tape meme.

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

Это кстати то, о чем я писал в комментариях в Вашем телеграмм канале. Лишь бы побыстрее выкатить релиз, а то, что в нем есть ошибки, никого не волнует. Надо же побыстрее выкатить пресс-релиз, в котором будет написано, какие Вы молодцы.

На исправленной версии я получил такие результаты на вашем проекте -
Первая компиляция сразу после открытия проекта (кеш окон еще не создан) - 13:25 (https://www.screencast.com/t/fDnRRkYsqQGp)
Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)
Первая компиляция сразу после открытия проекта (кеш окон был ранее создан) - 5:48 (https://www.screencast.com/t/dpYLPkgV4z5R)

Я кончено, не знаю, какие спеки Вашего компутера, но Вам не кажется, что 13 минут - это слишком много?
Для сравнения, на своем ПК сделал компиляцию сразу после открытия проекта на версиях 1.2.16 (https://disk.yandex.ru/i/ip3oEmGt0_7eyg) и 1.3.1 (https://disk.yandex.ru/i/DyvM8O1lJyGpyQ) - 7 и 5 минут соответственно. Небольшая разница, согласитесь. Все-таки ждешь вау-эффекта, когда Ваши сотрудники делают такие публичные заявления. Но тут можно парировать словами классика о том, что ваши ожидания - ваши проблемы.

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

В случае подобных ошибок просьба присылать отчет об ошибках в техподдержку

Если честно, то уже нет никакого желания. Во-первых, потому что уже сложилось впечатление, что у Вас нет какой-то цели сделать продукт лучше, просто идете какой-то дорогой. Во-вторых, я решил остаться на 1.2.16, потому что я не вижу чего-то принципиально хорошего, что могло бы побудить меня обновиться до текущей версии. Да и технического сопровождения у меня нет, смысла платить за него я не вижу, да и слишком хлопотно (спасибо всяким ФЗ и прочему шлаку) стало в моей конторе приобретать разного рода продукцию.

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

Тогда я не совсем понимаю, почему должна повысится производительность и скорость работы редактора проектов. Что тогда подразумевают Ваши сотрудники, когда на своих вебинарах заявляют, что в версии 1.3.1 решены проблемы быстродействия и ресурсоемкости редактора проектов?
То есть Firebird и так был медленным по причине однопоточности чтения и записи, но Вы решили еще где-то сбоку нагородить взаимодействие с Postgree, которое, по Вашим же словам, даст выигрыш только в НЕКОТОРЫХ проектах. Пока что это выглядит, как flex tape meme.

В Firebird выигрыш за счет кеширования результатов компиляции окон и многопоточной компиляции (Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)).
Что касается ресурсоемкости, то тут дело в том, что при наличия кеша окна не загружаются в память вообще, на видео 2 и 3 там видно, что память не превышает 6Гб, а при первой компиляции пока кеш не создан, расход был выше.
Выигрыш с Postgree будет на всех проектах, хотя бы за счет того, что процедура чтения из него выполняется в 4 раза быстрее. Также при работе происходит выгрузка неиспользуемых элементов, что снижает расход памяти. Позже напишем на данном проекте какие будут результаты.

Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз. Но за счет кеширования повторные запуски в процессе работы занимают минуту вместо 10 как было на 1.2 (на ней у меня компиляция после открытия заняла 14 минут, из них 4 - загрузка элементов и 10 - собственно компиляция, память доходила до 16Гб https://www.screencast.com/t/IDa2HYVEkSh)

Я кончено, не знаю, какие спеки Вашего компутера, но Вам не кажется, что 13 минут - это слишком много?
Для сравнения, на своем ПК сделал компиляцию сразу после открытия проекта на версиях 1.2.16 (https://disk.yandex.ru/i/ip3oEmGt0_7eyg) и 1.3.1 (https://disk.yandex.ru/i/DyvM8O1lJyGpyQ) - 7 и 5 минут соответственно. Небольшая разница, согласитесь. Все-таки ждешь вау-эффекта, когда Ваши сотрудники делают такие публичные заявления. Но тут можно парировать словами классика о том, что ваши ожидания - ваши проблемы.

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

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

На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.

Если честно, то уже нет никакого желания. Во-первых, потому что уже сложилось впечатление, что у Вас нет какой-то цели сделать продукт лучше, просто идете какой-то дорогой. Во-вторых, я решил остаться на 1.2.16, потому что я не вижу чего-то принципиально хорошего, что могло бы побудить меня обновиться до текущей версии. Да и технического сопровождения у меня нет, смысла платить за него я не вижу, да и слишком хлопотно (спасибо всяким ФЗ и прочему шлаку) стало в моей конторе приобретать разного рода продукцию.

Обращения об ошибках принимаются от всех пользователей, даже кто использует демо-версию или бесплатную

[b_aleks]

В Firebird выигрыш за счет кеширования результатов компиляции окон и многопоточной компиляции (Повторная компиляция - 1:08 (https://www.screencast.com/t/YOixL8t2iS)).
Что касается ресурсоемкости, то тут дело в том, что при наличия кеша окна не загружаются в память вообще, на видео 2 и 3 там видно, что память не превышает 6Гб, а при первой компиляции пока кеш не создан, расход был выше.
Выигрыш с Postgree будет на всех проектах, хотя бы за счет того, что процедура чтения из него выполняется в 4 раза быстрее. Также при работе происходит выгрузка неиспользуемых элементов, что снижает расход памяти. Позже напишем на данном проекте какие будут результаты.

Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 6 минут. А Вам самому нравится ждать такое время?

Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.

Да, я уже слышал от Ваших коллег, что мой проект сделан не совсем правильно, но я не вижу в этом ничего плохого.
Во-первых, с учетом того, сколько у Вас раньше было ошибок, я решил делать проект как можно проще, простота и надежность.
Во-вторых, все объекты у меня чем-то отличаются, поэтому делать кучу экземпляров на каждый уникальный элемент я не вижу смысла. То, что это как-то ускоряет разработку проекта - сомнительный аргумент. С учетом однотипной иерархии объектов и однотипным именованием элементов, дублированием я сделаю все гораздо быстрее, чем буду выискивать те самые "кирпичики", из которых мне требуется построить объект. В третьей версии Вашего продукта у меня был проект, который мне достался в наследство. Там все объекты были свалены в одну кучу, было много лишних элементов и связей, но почему-то все работало достаточно шустро.
В-третьих, переделывать такой большой проект, работа которого меня полностью устраивает, я не вижу смысла. Мое мнение в этом вопросе останется прежним - это не проект какой-то особенный, что он так долго экспортируется и тормозит, это редактор проектов такой особенный, что попросту не тянет.

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

Несколько раз перечитал, но так и не понял. О какой минуте идет речь? При описанном выше сценарии моей работы будет также 5 минут.

На моем видео видно, что во время компиляции окон загрузка доходит до 50% при 16 потоках (i7 11800H). Если бы в проекте было бы несколько узлов или несколько задач в узле, то параллельность была бы не только для мнемосхем.

Давайте не будем передергивать. Во-первых, до 50% загрузка доходила на короткий промежуток времени; большую часть времени Ваш процессор, так же, как и мой, находился в простое, нагрузка в среднем была 10-20%. Во-вторых, ни на одном из Ваших видео я так и не увидел нагрузку по ядрам. Почему-то я уверен, что там также будет загружено два ядра из восьми. В чем такая проблема реализовать использование всех ресурсов процессора и диска? При чем независимо от того, сколько там у меня узлов в проекте и какую операцию я делаю.
Почему какой-то винрар при архивировании небольшого файла стабильно (без всяких скачков) грузит все ядра? Почему Ваш продукт так не может?
винрар.png

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

Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 6 минут. А Вам самому нравится ждать такое время?

В случае 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. Но за счет возможности распараллеливать процессы компиляции и большей скорости работы БД основные сценарии сильно ускорились.

[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
Как мне кажется, если загрузить все ядра, то может быть эти операции будут осуществляться быстрее. Это я к тому, что есть над чем работать. То есть сейчас, как мне кажется, оптимизирован только процесс компиляции проекта, а остальные операции - не очень.

[asuwcc]

Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.

Если вы считаете ошибкой не задействовать экземпляры, то уберите возможность использовать наследников. Сделайте только экземпляры.
Тем более, если в библиотечный объект добавить сообщения (Тревоги), то в экземплярах их использовать нельзя, они удаляются. Доступны только в наследниках.

Интересно, в 1.3.1 добавили возможность использовать TagPrefix? Было упоминание про некие ссылки на объекты.
Событие - "Открытие окна" добавили?