EnumProcesses () против CreateToolhelp32Snapshot ()

Question

Мне было интересно, есть ли какие-либо различия - в основном в отношении производительности - между двумя функциями Win32 API EnumProcesses () и CreateToolhelp32Snapshot () для перечисления всех активных процессов и загруженных модулей.Или если один лучше другого использовать и почему.

Answer 1

Я думаю, что они в значительной степени одинаковы с точки зрения производительности (и результатов), поскольку они оба вызывают один и тот же базовый NT API, хотя CreateToolhelp32Snapshot () может иметь небольшие накладные расходы, так как создает объект раздела и копирует всю информацию в тогда как EnumProcesses () / EnumProcessModules () работают напрямую с предоставленными пользователем буферами. Впрочем, разница в производительности в реальном мире незначительна.

Я немного предпочитаю EnumProcesses (), поскольку он (IMO) более простой в использовании API, но CreateToolhelp32Snapshot () возвращает больше информации, если вам это нужно. Единственным недостатком EnumProcesses () является то, что вы должны вызывать его в цикле, поскольку вы, возможно, не выделили достаточно большой буфер; CreateToolhelp32Snapshot () позаботится об управлении буфером. На практике я просто выделяю буфер в стеке, достаточно большой, чтобы вместить 1024 идентификатора процесса или дескрипторы модуля; до сих пор я не сталкивался с системой, где хотя бы один из этих пределов был хотя бы отдаленно близок к достижению. Конечно, мы говорили то же самое о MAX_PATH не так давно, и теперь у нас возникают проблемы с этим ...

Answer 2

Вот результаты из нескольких функций:

• EnumProcesses: 16 мс, 207 процессов
• CreateToolhelp32Snapshot: 141 мс (16 мс), 207 процессов
• WTSEnumerateProcesses: 16 мсек, 207 процессов
• WTSEnumerateProcessesEx (WTS_CURRENT_SESSION): 16 мсек, 98 процессов
• WTSEnumerateProcessesEx (WTS_ANY_SESSION): 16 мсек, 207 процессов

Машина работаетWindows 8 с включенным UAC, пользователь не имеет прав (например, не имеет доступа к системным процессам).Основной процесс - 32-разрядный, машина - 64-разрядная, поэтому существует множество 64-разрядных процессов.Существуют: сеанс 0 для системы, сеанс 1 для текущего пользователя консоли, сеанс 2 для другого пользователя быстрого переключения.Всего 207 процессов (как 32-, так и 64-битных, включая псевдосистемный процесс). 207 также подтверждается Process Explorer.Среди этих 207 процессов: 23 процесса предназначены для сеанса 2, 98 процессов - для сеанса 1, а остальные - для сеанса 0.

Результаты приведены для цикла из 10 отдельных вызовов функций.Они воспроизводятся на 100% при каждом запуске.

Для CreateToolhelp32Snapshot основным результатом является вызов самого CreateToolhelp32Snapshot, а вторым результатом (в скобках) является цикл с First / Next.

Я думаю, что люди путают«перечислить все процессы» (получить PID) и «получить имя процесса / exe».Первый (enumerate) не имеет проблем с кросс-битностью x32 / x64.Но у последнего («get name») действительно есть проблемы - не каждый метод будет работать в x32 / x64.

Answer 3

Я точно не помню, но в отличие от CreateToolhelp32Snapshot (), EnumProcesses () имеет одно из двух или обоих ограничений: 1. Не перечисляет 64-битные процессы, если они вызваны из 32-битного процесса в x64 OS.2. Не перечисляет повышенные процессы в Vista и Win7.

Answer 4

CreateToolhelp32Snapshot FTW. EnumProcesses не перечисляет все системные процессы, как все экземпляры svchost.exe, по крайней мере в Win XP.

Answer 5

ИМО ключевое отличие заключается в требованиях привилегий. Я видел случаи, когда EnumProcesses() терпел неудачу, но CreateToolhelp32Snapshot() работал отлично.

Так что однажды мне нужно было написать код, который бы обнаруживал определенный процесс в системе и реагировал соответствующим образом. Я написал его, используя EnumProcesses(), и он отлично работал на моей машине, но не на машинах тестеров. Я просто переписал это с CreateToolhelp32Snapshot(), и я никогда не слышал о каких-либо проблемах с ним.