При обработке события ESL программа портебляет слишком много процессорного времени

[san]

На мой взгляд стоит обратить внимания на алгоритм обработки событий, явно не должны присутствовать такие "пики" потребления процессорного времени программой.
Картинка зафиксирована на ноутбуке (процессор достаточно мощный: Celeron N2830@2.16 GHz, двухядерный, ОС Windows 10)

Расшифровка подписей на картинке:
1."Простой" - пользователь и ещё один абонент в диспетчерской - ничего не происходит.(8-15%)

2. Активно переключаюсь между вкладками программы, перемещаю селекты, провоцирую многократные перерисовки (10-20%)
3. Каждый пик - событие mute или unmute у произвольного абонента (до 60%)
4. Удаляю пользователя из Диспетчерской, диспетчерская закрывается, затем автоматически туда добавляется пользователь и ещё абонент (до 80%)
5. Создание новой конф, затем добавление в неё абонента.

[alx]

У меня есть два, пожалуй, риторических вопроса.

1. Откуда известно, что нагрузка на CPU связана именно с событиями ESL? Если только со слов Дмитрия, то у меня вопрос: он пршел к такому выводы в результате проведенного исследования данной проблемы или просто сделал ни на чем не основанное предположение (уж простите, Дима, но много раз уже такое бывало)?
2. Когда-то уже довольно давно было устное обсуждение проблемы, суть которой сводилась к тому, что программа может не успевать обрабатывать события, поступающие из коммутатора (Саша жаловался на большие задержки реакции программы). Дима объяснил это тем, что программа перерисовывает элементы на экране (например список пользователей) при получении каждого события (например об изменении состояний пользователей), а события могут поступать чаще чем программа успевает обновлять экран. В качестве решения Сашей было предложено (в моем переводе) реализовать механизм отложенного обновления, суть которого заключалась в том, что при получении события обновляется лишь внутренняя информация в памяти программы и запускается таймер, по истечение которого выполняется обновление экрана. Был ли реализован такой механизм?

[san]

1. На самом деле, связь прожорливости с событиями ESL предположил я. Как минимум, прожорливой программа становится именно в тот момент, когда появляется событие.

[san]

Часть проблемы Дима обнаружил. По словам Димы это было связяно с выводом сообщений в Журнал.
В результате исправления пиковая загрузка CPU уменьшилась до 20-40%(зоны 3,4,5 на картинке).

[dimag]

r367

[dimag]

заменил текст редактор QTextEdit на QPlainTextEdit, запретил вывод списка пользователей, конференций, пользователей конференции до полного обновления содержимого соотвествующих списков.

[alx]

Так как старый код, взаимодействовавший с FS и обрабатывавший приходящие из FS события (классы ESL, Commands, Events) полностью удален из проекта, полностью переписан код, выводящий списки конференций, пользователей, записей и т.п. (старым остался только код редактирования пользователей), этот тикет можно считать неактуальным (см. r725). Заркываю его с резолюцией fixed, так как, вероятнее всего, новый код не будет иметь проблем, связанных с производительностью.

Если к новому коду будут какие-то нарекания, создавайте, пожалуйста, новый тикет.