Профилирование и оптимизация патчей и внешних PureData

Question

Я работал над синтезатором, построенным на Pd, и запускал его на BeagleBone Black. Для этого я написал несколько абстракций и два внешних. Прямо сейчас синтезатор является однотонным и использует 100% CPU при запуске, вызывая много слышимых щелчков и артефактов. Примерно через 5 секунд он "стабилизируется" до 75% процессора, а задержка и звук довольно хорошие.

Теперь мне нужно сделать синтезатор полифоническим, чтобы освободить процессорное время для дополнительных голосов. Для этого я думаю о создании Pd с символами отладки и запуске моего патча через профилировщик, такой как Callgrind/KCacheGrind, чтобы попытаться выяснить, где происходит наибольшее потребление ресурсов процессора, и оптимизировать его.

Кто-нибудь может поделиться какими-то приемами или советами, используемыми для оптимизации Pd патчей и внешних программ? Существуют ли какие-либо инструменты, специфичные для Pd, для такого рода задач? Любая причина, почему мой подход будет или не будет работать?

Answer 1

Ваш патч кажется тяжелым для исполнения. Это означает, что вы выполняете много вычислений в любое время, когда запускаете синтезатор. Что это за синтезатор?

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

Удачи!

Answer 2

Использование полноценных инструментов профилирования, конечно, вариант. Основным недостатком является то, что они значительно замедляют работу системы, поэтому вам может потребоваться полностью автоматизированный контрольный пример (вместо того, чтобы полагаться на характер среды в реальном времени).

Что касается профилирования в патче, лучшее предложение Pd является [realtime] объект, который вы можете использовать для измерения необходимого времени (времянастенных часов, а не логическое время, которое должно быть равно нулю) для выполнения определенной операции в домене сообщений. Тем не менее, это не может использоваться для объектов сигнала!

Вот пример для профилирования полного выполнения поддерева (в пределах [pd complicated] субпатч) и нескольких выбранных объектов (в пределах [pd complex] subpatch)

Из вашего описания кажется, что ваш патч тратит много времени во время инициализации (при максимальной загрузке процессора, поэтому требуется некоторое время, чтобы опуститься ниже 100%), что, скорее всего, указывает на проблемы в домене сообщений.

Что касается области сигнала, типичные проблемы включают в себя повторную блокировку до небольших размеров блока ([block~ 1]) и вычисление неиспользованных голосов (отключите их с помощью [switch~] если они добавляют к выходу сигнала).