Я работаю над приложением замера звука MacOS / X на основе Qt, которое содержит виджеты замера звука (потенциально их много), каждый из которых должен обновляться каждые 50 мс (т. Е. С частотой 20 Гц).
Программа работает, но при одновременном обновлении большого количества счетчиков она использует много процессорного времени и может зависнуть (spinny-color-wheel, о нет!).
Странная вещь заключается в следующем: изначально это приложение просто вызывало update () для виджета измерителя всякий раз, когда значение измерителя изменялось, и, следовательно, весь виджет-измеритель перерисовывался бы каждые 50 мс. Тем не менее, я подумал, что был бы умен и вычислил бы только ту площадь счетчика, которую нужно перерисовать, и перерисовал бы только ту часть виджета (например, update (x, y, w, h), где y и h рассчитывается на основе старых и новых значений счетчика). Однако, когда я это реализовал, он фактически увеличил загрузку ЦП в четыре раза (!) ... хотя приложение рисовало на 50% меньше пикселей в секунду.
Может кто-нибудь объяснить, почему эта оптимизация действительно оказывается пессимизацией? Я разместил тривиальный пример приложения, демонстрирующий эффект, здесь:
http://www.lcscanada.com/jaf/meter_test.zip
Когда я компилирую (qmake; make) указанное выше приложение и запускаю его так:
$ ./meter.app/Contents/MacOS/meter 72
Meter: Using numMeters=72 (partial updates ENABLED)
... top показывает процесс с использованием ~ 50% ЦП.
Когда я отключаю логику умного-частичного обновления, запустив ее так:
$ ./meter.app/Contents/MacOS/meter 72 disable_partial_updates
Meter: Using numMeters=72 (partial updates DISABLED)
... top показывает процесс, использующий только ~ 12% ЦП. А? Разве в этом случае не нужно больше процессора, а не меньше?
Я пытался профилировать приложение с помощью Shark, но результаты не имели для меня большого значения. Я использую Snow Leopard на 8-ядерном Xeon Mac Pro.