Цитата Сообщение от KrAssor Посмотреть сообщение
Могу ошибаться, пусть SCADAMaster4D меня поправит:
1. Назначение в узел заставляет весь объект крутиться в основной задаче узла.
2. Для меньших тормозов оптимизируйте выполнение ваших объектов. Для менее приоритетных алгоритмов создавайте отдельные задачи с большим временем выполнения. Не запихивайте все программы и объекты в основную задачу - в 90% случаев они там крутятся и обрабатываются просто так. Например: есть контрол со значением температуры. По клику появляется всплывающее окно с графиком, расчетами, контролами регулировки оборудования - это все можно засунуть в задачу по вызову, не нужно это крутить в периодической задаче, тем более в высокоприоритетной основной.
3. Если я правильно понимаю, то каждая задача - это отдельный поток. Соответственно выполнение всех алгоритмов в одном потоке снижает эффективность использования проца.
В целом, Вы правы. Но это касается только серверной части. Здесь нужно разделять быстродействие прикладных программ, исполняемых сервером, и быстродействие визуализации – кода JS, исполняемого графическим клиентом. Скорости исполнения этих задач почти не связаны между собой.

Быстродействие серверной части.
Фактическое время и период выполнения прикладных задач сервера можно посмотреть через диагностический порт 31550 (более подробно в справке в разделе «Как получить диагностическую информацию среды исполнения»). По умолчанию период задачи установлен 100 миллисекунд. Разработчик проекта должен проследить, чтобы фактическое время выполнения задачи даже в крайнем случае не превышало бы 80% от периода. А лучше – не более 50%. Если время фактического выполнения приближается к периоду или превышает его (что недопустимо), то необходимо увеличить период вызова задачи. Например, если все компоненты проекта назначены для исполнения в основную задачу и время её фактического выполнения составляет в среднем 300 миллисекунд, то период исполнения основной задачи желательно установить не менее 500 миллисекунд. При этом, те части системы управления, для которых время реакции 500 миллисекунд недопустимо велико (например, защиты и блокировки), то их выделяют в отдельную задачу с более частым периодом исполнения (например, 50 миллисекунд). У этой более быстрой задачи так же необходимо следить, чтобы фактическое время не превышало бы периодичность вызова. Чтобы обеспечить возможность сокращения периода вызова, более быстрая задача должна содержать как можно меньше программных компонентов. Теоретически, задачи запускаются в разных потоках параллельно и не должны влиять друг на друга. На практике же это сильно зависит от разных факторов, в том числе от работы диспетчера потоков операционной системы и общего количества потоков. Поэтому нужно следить не только за фактическим временем выполнения каждой задачи, но за фактическим периодом вызова – следить, чтобы он не увеличивался относительно заданного.

Теперь о быстродействии визуализации.
Насколько мы видим, основная часть нареканий относится именно к ней. Быстродействие большинства происходящих на экране изменений– открытие новых окон, появление всплывающих, анимация различных элементов - обусловлена скоростью исполнения скриптов в среде визуализации. За последнее время мы проделали большую работу по оптимизации их исполнения. В частности, был полностью переписан движок визуализации с учётом современных технологий. Это позволило увеличить быстродействие визуализации по некоторым показателям до 10 раз. Новая версия движка визуализации будет доступна в тестовом режиме в версии 1.2.7.