Гораздо полезнее было бы замерять время выполнения хуков отдельно, их частоту, и выводить наиболее критические, при чем %плагин%, %название хука% - %время%, %кол-во вызовов%. При этом отфильтровывать GC. Сомневаюсь, что это возможно средствами плагина, правда.
Дело в том, что в таком списке как сейчас, будут лидировать плагины во время выполнения которых был запущен сборщик мусора, а это вовсе не значит, что плагин лагающий. Это означает скорее, что хук из данного плагина выполняется наиболее часто.
В чатах я писал пару раз про это, продублирую еще раз здесь. К примеру Vanish, там в хуке на каждый OnPlayerTick выполняется 1-2 логические операции (когда никто не висит в ванише). Эта нагрузка абсолютно несущественна для сервера. Но т.к. хук выполняется на столько часто, существует большая вероятность того, что GC решит почистить память как раз во время работы ваниша. Тогда сервер заморозится, и в логах будет написано, что GC приостановил поток выполнения на хуке ваниша. По этой причине практически невозможно отследить, виноват плагин в слишком частом вызове GC или нет.
Чтобы понять это все, еще полезно представить игровой процесс. Игровая логика и код плагинов выполняются во фреймах, в одном потоке. Каждый фрейм сначала (скорее всего) выполняется игровая логика, а потом плагины по-очереди. Если мы ограничим fps сервера до 30, то по идее, на каждый фрейм выделяется около 33 мс. Если что-то не успеет выполниться за это время (игровая логика, либо плагины), то возникнет лаг, зачастую превышающий время задержки. По-этому одно "общее время работы плагина" практически ничего не покажет. Даже если отфильтровать GC.
Пока писал, пришел на ум еще один вид профайлинга: детектить, если в одном ивенте набирается критически много (либо несколько долго выполняющихся) хуков. К примеру, плагины вполне могут загадить какой-нибудь OnPlayerInit, я даже знаю примеры.
В общем все намного сложнее, и скорее всего такую вещь нельзя добавлять на сервер на постояной основе (во всяком случае, мониторинг каждого фрейма)