Страница 4 из 5 ПерваяПервая ... 2345 ПоследняяПоследняя
Показано с 31 по 40 из 43

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

  1. #31

    По умолчанию

    Цитата Сообщение от Larrrik Посмотреть сообщение
    Спустя месяцы знакомства с MS4D кажется совершенно очевидным, что единственной целью разработчиков является сделать так, чтобы пользователи страдали от всего....
    Ага, страдать и каяться...

  2. #32

    По умолчанию

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    Особенность этого проекта, что в нем никак не задействованы экземпляры, однотипные объекты с окнами просто продублированы много раз.
    Небольшой апдейт по поводу Вашей объектной модели. Вы сами вообще представляете, как использовать экземпляры, где каждое окно (даже если оно сильно похоже на такое же окно другого объекта) уникально? Такая же ситуация с программами. С учетом того, что экземпляры редактировать и видоизменять нельзя, то я слабо представляю, как их использовать в таком проекте. Каждое уникальное окно или программу кидать в библиотеку, а в дереве использовать их как экземпляры? Никакого выигрыша в скорости работы проекта в редакторе не будет.

    И еще. Что значит "особенность" проекта? Вы сами везде заявляете, что Ваша платформа такая чудесная и прекрасная, что подходит под разработку проектов любого масштаба и сложности. Или как обычно, пользователи все не так поняли? В очередной раз убеждаюсь, что заявления Ваших менеджеров или кого-то еще абсолютно оторваны от реальности.

  3. #33

    По умолчанию

    Цитата Сообщение от b_aleks Посмотреть сообщение
    Вы сейчас пытаетесь навязать то, что при каких-то определенных условиях, будь то повторная компиляция или кеширование элементов, редактор будет работать быстрее.
    Я не знаю, как большинство пользователей пользуется и работает с Вашим редактором, но опишу свое видение, почему я вообще затрагиваю эту тему. У меня есть готовый проект, который работает уже не первый год. И в большинстве случаев мне требуется либо поменять что-то в настройках протокола (в связи с заменой оборудования), либо добавить какой-то новый объект дублированием другого и последующим исправлением. А после переоткрыть редактор, чтобы освободить ОЗУ, и экспортировать проект. То есть получаем случай из Вашего первого видео - ждем 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. Но за счет возможности распараллеливать процессы компиляции и большей скорости работы БД основные сценарии сильно ускорились.

  4. #34

    По умолчанию

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    В случае 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", в то время как этот проект в редакторе имеет осмысленное название.
    Последний раз редактировалось b_aleks2; 16.03.2023 в 12:27.

  5. #35

    По умолчанию

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

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

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

    Цитата Сообщение от b_aleks2 Посмотреть сообщение
    большие окна, где выведены все вложенные объекты, открываются по несколько минут;
    Какое именно окно открывали? На видео не увидел.

  6. #36

    По умолчанию

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    На какой версии вы проверяли?
    Версия: 1.3.1.31444(MPLCD_1_3_20230314.1)

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    Какое именно окно открывали? На видео не увидел.
    2023-03-16_12-34-23.png

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

  7. #37

    По умолчанию

    Цитата Сообщение от b_aleks2 Посмотреть сообщение
    Да. То, о чем Вы пишете - экспорт проекта, теперь происходит за полторы минуты. Но и тут такая же ситуация с нагрузкой - 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 раза.

    Цитата Сообщение от b_aleks2 Посмотреть сообщение
    большие окна, где выведены все вложенные объекты, открываются по несколько минут;
    мнемосхемы объектов открываются по ~10 секунд;
    программы периодически компилируются по ~10 секунд;
    деревья раскрываются по несколько секунд;
    Действительно в Postgre были неоптимальные запросы загрузки элементов по ссылкам из программ/окон. Поправили это, теперь выглядит так
    https://www.screencast.com/t/geCfzz2JThU

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

  8. #38

    По умолчанию

    Цитата Сообщение от b_aleks2 Посмотреть сообщение
    Небольшой апдейт по поводу Вашей объектной модели. Вы сами вообще представляете, как использовать экземпляры, где каждое окно (даже если оно сильно похоже на такое же окно другого объекта) уникально? Такая же ситуация с программами. С учетом того, что экземпляры редактировать и видоизменять нельзя, то я слабо представляю, как их использовать в таком проекте. Каждое уникальное окно или программу кидать в библиотеку, а в дереве использовать их как экземпляры? Никакого выигрыша в скорости работы проекта в редакторе не будет.
    Если целиком типизировать объект не получается, можно типизировать его отдельные программы/окна, которые совпадают у всех объектов. Еще можно добавить в окно/программу настройки, по которым менять содержимое/поведение, использовать стековую панель/таблицу для отображение динамического набора элементов, привязанного к массиву структур.

  9. #39

    По умолчанию

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    То есть доработки по параллельной компиляции окон также ускорили сценарий пересоздания кэша окон 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
    Как мне кажется, если загрузить все ядра, то может быть эти операции будут осуществляться быстрее. Это я к тому, что есть над чем работать. То есть сейчас, как мне кажется, оптимизирован только процесс компиляции проекта, а остальные операции - не очень.
    Последний раз редактировалось b_aleks2; 20.03.2023 в 10:35.

  10. #40

    По умолчанию

    Цитата Сообщение от Виктор Момотов Посмотреть сообщение
    Если целиком типизировать объект не получается, можно типизировать его отдельные программы/окна, которые совпадают у всех объектов. Еще можно добавить в окно/программу настройки, по которым менять содержимое/поведение, использовать стековую панель/таблицу для отображение динамического набора элементов, привязанного к массиву структур.
    Для примера. Как сделать библиотечное окно с трендом, использовать его с отношением "Ссылается" (ведь только такое отношение ускорит проект), но при этом надо сделать так, чтобы у каждого его экземпляра было разное количество перьев?

Страница 4 из 5 ПерваяПервая ... 2345 ПоследняяПоследняя

Похожие темы

  1. Быстродействие MasterScada 4d
    от volgogaz в разделе Master SCADA 4D
    Ответов: 29
    Последнее сообщение: 09.08.2022, 14:09
  2. Ответов: 11
    Последнее сообщение: 15.10.2021, 04:39
  3. Создание сетевых проектов в MasterSCADA 4D
    от DimBan в разделе Master SCADA 4D
    Ответов: 2
    Последнее сообщение: 15.09.2020, 17:15
  4. Ответов: 12
    Последнее сообщение: 10.12.2015, 17:34
  5. БУСТ 2 :confused:
    от kanava в разделе Эксплуатация
    Ответов: 2
    Последнее сообщение: 10.06.2010, 11:52

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •