AHK, Windows API: Вычисление момента окончания загрузки приложения

Постараюсь объяснить. Все мы знаем, что тяжеловесные программы грузятся дольше лёгких. Фотошоп, например, грузится аж до 20 секунд, а Аутлук всего за 3с. Как мы это определяем? По ощущениям, так? И мы по ощущениям эту разницу чувствуем, а значит существует некий промежуток времени, свой на каждой системе для каждого приложения, в течение которого программа грузится. Из этого следует, что должен существовать некий момент, в который программа заканчивает свою загрузку (иначе мы бы не чувствовали разницы). Остаётся только этот момент программно найти.
Конечно, я допускаю, что этот момент может быть не в одну миллисекунду, а длится некоторое время, вплоть до 1 секунды это может быть, по моим наблюдениям. Но в таком случае, мне надо найти среднее арифметическое всех значений на выходе из момента загрузки, а это не сложно, это уже дело техники.
Главное – критерий. Что взять за критерий. Есть вот вариант с подсчётом загрузки процессора, но как его реализовать –ума не приложу. Мне нужен критерий, сам алгоритм.

Т.е. само "выражение" вполне определённо, а неопределено то, о чём в нём говорится.

При загрузке процесса значение выделяемой под него памяти более\менее изменяется в сторону увеличения и когда он полностью загружен останавливается.

Может надо с какой-то периодичностью проверять это значение и при совпадении с предыдущим...

Так-так, это уже кое-что. Вопрос в том – как это померить программно. Как измерить отклик? Хотя, эта идея мне не очень нравится – отклики измерять наверняка дольше, чем время выгрузки из памяти, а это значит что можно здорово потерять в точности измерений.

Так ведь это не помеха же! Для моей задачи это неважно. Для меня главное найти этот момент в конкретном случае, а не в общем случае.

Да, идея. Только что будет надёжнее: через память, или через загрузку процессора?

Вроде нашёл:

ProcessName := "notepad++.exe"
Process, Exist, % ProcessName

msgbox % "Процессс " . ProcessName . "`rиспользует  " 
         . GetProcessMemoryInfo( ErrorLevel )
         . "  килобайт оперативной памяти"

GetProcessMemoryInfo( PID ) 
{
   hProcess := DllCall( "OpenProcess", UInt, 0x10|0x400, Int, false, UInt, pid )
   VarSetCapacity( memCounters, 40, 0 )
   DllCall( "psapi.dll\GetProcessMemoryInfo", UInt, hProcess, UInt, &memCounters, UInt, 40 )
   DllCall( "CloseHandle", UInt, hProcess )
   Return NumGet( memCounters, 12, "UInt" ) // 1024
}

Вопрос: почему значение не совпадает со значением из диспетчером задач?

Вкладка "Процессы", колонка "Память (частный рабочий набор)" - значение всегда меньше чем в скрипте.

Может потому-что: Win-7 64-bit, AutoHotkey_L Unicode 32-bit 1.1.09.03

creature.ws
Точно, так и есть.

Вообще, да, это сработает. Значит, если другого критерия никто не предложит, будем считать, что для данной задачи это лучший вариант.
Тогда, следующий этап: каков будет алгоритм работы с функцией GetProcessMemoryInfo?
Что берём, с чем складываем/умножаем и т.д. Там есть два входящих значения (хэндл и ещё что-то) и один исходящий. Что с ним делать, как его интерпретировать? В англоязычном описании сказано, что результат работы функции представляет собой некую структуру данных (массив или что?), но вот что с этой структурой делать, как из неё вытащить нужную информацию?
То же касается GetProcessTimes (для опроса загруженности процессора). Здесь, как я уже писал, не могу понять, чем эта функция может мне помочь.

Украдено отсюда

#Persistent
ProcessName := "XBMC.exe"
Process, Wait, % ProcessName 
PID := ErrorLevel
SetTimer, ShowToolTip
ShowToolTip:
    ToolTip % GetProcessTimes(PID) . "`%`r" . GetProcessMemoryInfo( PID ) . " kb", 10,10
    Return
    
GetProcessTimes( PID )    { 
    Static oldKrnlTime, oldUserTime, newKrnlTime, newUserTime  
    oldKrnlTime := newKrnlTime , oldUserTime := newUserTime  
    hProc := DllCall("OpenProcess", "Uint", 0x400, "int", 0, "Uint", pid) 
    DllCall("GetProcessTimes", "Uint", hProc, "int64P", CreationTime, "int64P"
            , ExitTime, "int64P", newKrnlTime, "int64P", newUserTime)  
    DllCall("CloseHandle", "Uint", hProc) 
    Return (newKrnlTime-oldKrnlTime + newUserTime-oldUserTime)//100000 
}

GetProcessMemoryInfo( PID )   {
    hProcess := DllCall( "OpenProcess", UInt, 0x10|0x400, Int, false, UInt, pid )
    VarSetCapacity( memCounters, 40, 0 )
    DllCall( "psapi.dll\GetProcessMemoryInfo", UInt, hProcess, UInt, &memCounters, UInt, 40 )
    DllCall( "CloseHandle", UInt, hProcess )
    Return NumGet( memCounters, 12, "UInt" ) // 1024
}

Изменение чего вы хотите увидеть за 2мс?

Извлекайте некий КПД мощности процессора машины, и в соответствии с ним задавайте тайминги опроса.

Там просто извлекается потребление указанным процессом: памяти и процессорного времени. Что вы хотите умножать?

Как именно GetProcessTimes и GetProcessMemoryInfo извлекают данные я тоже не понимаю, но если вы имеете значеня которые вам нужны, что именно вы хотите понять?

Так вы  просто словами опишите желаемый алгоритм.

Всё верно. Из этой структуры скрипт читает число по смещению 12 байт, т.е. поле WorkingSetSize, и делит его на 1024, переводя байты в килобайты.

В случае использования AutoHotkey x64, смещение уже будет 16 байт и сам WorkingSetSize будет 64-битным числом.

Вроде была идея проверять значение памяти в цикле. Попробуйте её реализовать.

Вот примерный алгоритм, который я составил для этой ситуации:
1. Сразу приложение не запускаем: берём несколько секунд на вычисление среднего значения используемой памяти, а потом уже – запускаем.
   a. В течение нескольких секунд в цикле проверяем текущее значение используемой оперативной памяти (WinAPI: GetProcessMemoryInfo), затем вычисляем среднее арифметическое (оно пригодится позже, вне основного модуля). Это значение ОЗУ1. То же делаем с загрузкой процессора (в том же цикле). Это значение ПРОЦ1. Т.е. мы получаем значения загрузки ОЗУ и ЦП в нормальном режиме (когда приложение ещё не запущено).
   b. Запускаем приложение, засекаем момент запуска (* возможно, он засекается самой системой, значение можно получить из функции GetProcessTimes ?). Сразу после запуска начинаем проверять уровень использования ОЗУ, в цикле.
2. Вычисляем момент окончания загрузки и засекаем его во времени.
   a. В цикле (без тайминга) проверяем текущее значение загрузки ОЗУ и за-поминаем предыдущее, если текущее значение равно предыдущему, или меньше его, то начинаем проверку загрузки процессора.
      i. На первом шаге цикла, пока у нас нет ср.арифм. значения, сравниваем текущее разовое значение с ПРОЦ1. Если они примерно равны (надо учесть допустимый предел колебания в несколько про-центов), то считаем, что приложение предположительно уже загрузилось, запоминаем время и даём 2с на дополнительный блок обработки ошибочного значения.
      ii. На каждом цикле проверки загрузки процессора считаем ср.арифм. этой загрузки и сравниваем со значением ПРОЦ1. Если оно совпадает (учтя допустимый предел в несколько процентов) с ПРОЦ1, то считаем, что приложение предположительно уже загрузилось, запоминаем время и даём 2с на дополнительный блок обработки ошибочного значения.
         1. Блок обработки ошибочного значения: в течение двух секунд продолжаем опрашивать процессор и память. Если загрузка процессора опять идёт вверх, или увеличивается используемая ОЗУ, то считаем остановку таймера ошибочной и возвращаемся к предыдущим блокам.
         2. Если же за эти 2с значимых изменений не происходит, то считаем ту остановку таймера правильной и идём дальше.
3. Вычитаем из момента окончания загрузки момент его начала и получаем искомое время загрузки приложения.

...

Кстати приведите код получающий общую загруженность процессора с помощью GetSystemTimes.

И не пойму зачем всё таки общая загрузка проца, если вас в итоге интересует конкретное приложение, а винда может грузить проц чем то другим.

Интересно. Надо это обдумать. Дельта это как я понимаю изменение на выбранном промежутке? Правда, мне нужно узнать не в промежутке, а в текущий момент, но суть одна, видимо.

Понял. Это очень хорошо, что Винда сама засекает момент начала - меньше проблем. Жаль, Винда не умеет засекать момент конца загрузки.
А вот с остальным вы меня всё-таки запутали. По идее, раз мне нужно узнать, в какой момент приложение загрузилось, то логично использовать GetProcessTimes (раз нас интересует процесс, то процесс мы и проверяем). С другой стороны, при помощи GetSystemTimes тоже можно узнать искомое - по общему графику изменений.
Александр, приведите пож. такой же код, как вы приводили, только для GetProcessTimes. Там ведь нет idletime.

1 - для моих целей это не важно. Естественно там полно других приложений.
2 - значит нужна общая загруженность по всем ядрам и процессорам (либо только того ядра, что обрабатывает данный процесс); про потоки у приложения -- опять же, не надо усложнять - если потоков много, значит надо узнать когда загрузился последний из них
3 - да, у Хромого штук пять процессов, коли не больше, но мне, в таком случае, нужно узнать когда загрузился последний из них

Ну значит его надо создать, и дать ему правильное определение, которое соответствовало бы реальной ситуации и учитывало бы все нюансы. И неплохо бы соответствующую функцию добавить в WinAPI.
А ваш код я не понял совершенно. Но я ещё подумаю.

Вы пример из сообщения #23 попробовали использовать на реальных приложениях, «конец загрузки» которых вам хочется отловить?

Нет пока. Я ещё на стадии планирования. К тому же, я в программе буду использовать только то, что мне совершенно понятно, а там ещё разбираться надо. Но спасибо, конечно. Как только дойдёт до практики - обязательно загляну на форум за вашим примером.
Далее. Есть всё-таки ещё один момент, который остался непонятым. Для начала, я расписал предложенные формулы понятным языком:
Загруженность процессора определяется из GetSystemTimes по следующей формуле: (deltaKernelTime+deltaUserTime)/(deltaKernelTime+deltaUserTime+deltaIdleTime), т.е. мы «общее время работы» делим на «общее время работы + время простоя», иными словами мы время работы делим на общее время.
Также, загруженность процессора одним приложением можно узнать так (при помощи двух функций: GetProcessTimes и GetSystemTimes):
(deltaProcessKernelTime+deltaProcessUserTime)/(deltaSystemKernelTime+deltaSystemUserTime+deltaSystemIdleTime), т.е. мы «общее время работы, полученное из GetProcessTimes» делим на «сумму трёх значений (общего времени работы (это 2 значения) и простоя (это ещё одно)), полученных из GetSystemTimes». Иными словами, мы общее время работы процесса делим на общее время системы.
Но тут кроется подвох. Вот, если мы возьмём к примеру, 10 секунд, как общее время, и, скажем, 3 секунды как время работы, то тут всё понятно - делим одно на другое, получаем проценты. Но мне-то нужен момент времени, а не период, а значит эти наши условные 10с превращаются в точку, как и 3с. Если и 3с и 10с являются точками, то есть нулями, то при делении вообще будет ошибка (или бесконечность, я не знаю, но в любом случае - не то что нам нужно). Как с этим быть?

В этом мире много забавного. Вы же тоже почему-то со мной на ты общаетесь. А ведь я вас даже не знаю - это ли не забавно? Впрочем, я не против, тем более что вы мне помогли. Ну или "ты помог".
На счёт определения - я дал идею, а дальше будь что будет. Рано или поздно всё это будет вшито в ядро, технологии не стоят на месте. Кто этим будет заниматься я не знаю, кто захочет - тот и будет.
А то у нас тут 21 век, а программисты до сих пор не придумали как осуществить нормальный удобный (в один клик или вроде того) способ, например, вставлять текст из Ворда на форум. Уже не первое десятилетие существует интернет, уже вовсю пропагандируется вэб 2.0, но мы по-прежнему вручную делаем форматирование, которое пропадает при переносе из Ворда на сайты (а если сохраняется, то очень сильно отличается от оригинала). Впрочем возможно, с появлением HTML 5 что-то изменится. Вот и про определение момента конца загрузки - та же песня.

А причём тут 21 век? Или программирование и интернет появились с первого дня "нашей эры"...

А вы сами пробовали? Вроде как в переменной "ClipboardAll" есть всё для этого необходимое.