Увеличьте производительность PYKD heap_stat, отключив RtlValidSecurityDescriptor

Question

Работая с heap_stat (сценарий Python на основе библиотеки PYKD для запуска сценариев Python в среде Windbg), я разочарован тем, что этот сценарий требует огромного времени для выполнения своей работы.

Итак, я начал сеанс профилирования, используя " Very Sleepy", и это дало следующий результат:

Name                        Exclusive  Inclusive  % Excl.    %Incl.   Module
RtlValidSecurityDescriptor   2561.56s   5123.12s   50.00%   100.00%    ntdll
ZwWaitForSingleObject        1280.78s   1280.78s   25.00%    25.00%    ntdll
NtUserWaitMessage            1279.73s   1279.73s   24.98%    24.98%   win32u

Как видите, большую часть времени проводит в функции, проверяющей некоторую достоверность (что, я думаю, не нужно). Есть ли способ отключить эту проверку (конфигурация Windows, настройки реестра, ...)?

Изменить после первого комментария
Как xperf анализ был запрошен, я выполнил следующее xperf команды:

Начать профилирование:

xperf -start "DDS_LoggerName" -StackWalk ObjectCreate+ObjectDelete+ObjectReference -heap -Pids 28068

Остановить профилирование:

xperf -stop "DDS_LoggerName"

Я открыл результат (неполный, потому что сначала хотел посмотреть, как выглядит результат), используя Windows Performance Analyzer, но это не имеет смысла для меня. Я верю своему xperf Конфигурация плохая. Как мне нужно запустить xperf профилирование, чтобы можно было измерить, какая функция занимает какое время?

Answer 1

Я видел ваш журнал xperf и вот результаты:

25% ЦП получил вызов heap_output = dbgCommand('! Heap -h 0'). Split('\n')

Цикл 75% для heap_block в heap_output: основной потребитель CPU - pykd.ptrPtr

Основной причиной потери ЦП является массивный внутренний вызов dbgeng!FlushCallback от Debug Engine. Фактически все функции Debug Engine вызывают этот метод, и я не понимаю, почему.

Я могу посоветовать вам сделать рефакторинг heap_stat.py и переписать вашу собственную функцию ptrPtr с помощью ptrDword или ptrQword, это может уменьшить потери процессора.