Коротко об Execution system
В LabVIEW шесть потоков (систем исполнения):
- user interface - отвечает за пользовательский интерфейс. В многопоточных приложениях ведет себя так же, как и в однопоточных. VI работают в потоке пользовательского интерфейса без проблем, но система исполнения чередует совместную многозадачность и реагирование на действия пользователя – вот тут подводные камни и прячутся. В нагруженных системах интерфейсная часть может сильно «подвешивать» программу при том, что процессор будет загружен далеко не на 100%
- standard – выполняется в отдельных от пользовательского интерфейса потоках.
- instrument I/O – для периферии вроде VISA, GPIB и последовательного ввода/вывода.
- data acquisition – для сбора данных (DAQms и пр).
- other 1 и other 2 – если standard не хватает.
- same as caller – рекомендуемая настройка для subVI для запуска в той же системе исполнения, что и вызвавший VI.
Базово функции исполняются в стандартном потоке, но, если нужно обновить индикатор, в дело вступает UI поток. А неприятное в этом то, что остальные части функции начинают подтормаживать.
Вот тут интересный вопрос – а на сколько подтормаживать?
Для тестов я выбрал упрощённую модель системы:
Часть кода отвечает за сбор данных, а проще говоря, генератор случайных чисел создаёт массив заданной длины. Операция повторяется много раз, после чего в очередь отправляется время выполнения. Так же замечу, что очередь специально создаётся размером 1, так что поток «сбора данных» будет ждать, пока обработчик выполнит свою часть задачи. Это сделано для упрощения замеров времени. Сама начинка оформлена в виде subVI с режимом inline, что позволит использовать одинаковые функции в тестах, при этом без затрат времени на вызов функций.
Второй участок кода отвечает за обработку. Чтобы нагрузить процессор, для каждой точки вычисляется синус и косинус, сумма результатов, да ещё и экспонента в придачу с тангенсом. Всё это усредняется и пересылается в поток интерфейса. Если же размер полученного массива равен 1, то программа понимает, что это время исполнения предыдущего блока кода, и это значение портить не нужно, значение пересылается как есть.
И, наконец, интерфейсная часть.
Здесь происходит проверка, и время выполнения отображается на графике. Остальные значения отбрасываются как не существенные для теста.
Интересное же происходит в нижней части цикла. Программа на каждой итерации меняет вид точки графика с результатами и смещает само окно программы. Кроме того, таймаут ожидания очереди равен нулю, так что программа будет пытаться забрать все ресурсы, что сможет.
Пора запустить тест.
Первые сравнения проведу по описанной схеме.
Из графиков результатов, видим, что разнесение операций по потокам (системам исполнения) ускоряет программу в 5-20 раз.
Мало какие программы активно манипулируют с окнами, поэтому убираю вызовы property node и повторяю тест.
Время выполнения задач по-прежнему различается в 5 раз.
Вывод: используйте возможность оптимизировать скорость выполнения кода и разносите части программы по потокам в соответствии с задачами: сбор данных, обработка, интерфейс.
На видео можно увидеть, как проходили тесты
Если нет желания изучать все эти тонкости, обращайтесь к профессионалам: https://shevelev.pro