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

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

Тогда я не совсем понимаю, почему должна повысится производительность и скорость работы редактора проектов. Что тогда подразумевают Ваши сотрудники, когда на своих вебинарах заявляют, что в версии 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, потому что я не вижу чего-то принципиально хорошего, что могло бы побудить меня обновиться до текущей версии. Да и технического сопровождения у меня нет, смысла платить за него я не вижу, да и слишком хлопотно (спасибо всяким ФЗ и прочему шлаку) стало в моей конторе приобретать разного рода продукцию.

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