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

[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