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

GetProcessTimes,GetThreadTimes

А GetTickCount не будет работать, если взять его в начале программы и в конце. А потом вычесть?

Не хочется думать, что автор не понимает, как вычисляются промежутки между двумя точками времени.
Скорее уж его интересует время, которое программа реально работала, а не простаивала.
Добавлено @ 22:35
Добавлю, что GetTickCount не поможет. Скорее уж просто Now в начале и в нужный момент времени.

У меня есть программы, которые работают месяцами. Тут GetTickCount бессилен.

У меня программа консольная. И вы правы GetTickCount бессилен он выдаёт не точное время, а приблизительное. Дайте, пожалуйста, пример как использовать функцию GetProcessTimes.

это как - приблизительное?

а почему не хочешь сделать как сказал Демо?

Это вряд ли. GetTickCount выдает количество миллисикунд, прошедшее со времени последней загрузки системы. Поэтому приблизительное время GEtTickCount выдавать не может. Другое дело, если у тебя программа работает больше 49,7 дней непрерывно. В этом случае отсчет начинается с нуля.

Все же, что тебе нужно?
Если вычислить, промежуток времени, в котором работала твоя программа, то см. Albinos_X, если вычислить, сколько процессорного времени заняла программа, тогда см. первый ответ на твой вопрос.

Это сообщение отредактировал(а) Демо - 19.2.2006, 12:37

Спасибо!!!
Сколько динамической памяти заняло!!! Как унать!!!

GlobalMemoryStatus

Так вот текст strLog:
Разница времени: 0 минут 0 секунд 0 милисекунд 

Запись в файл длится менее одной миллисекунды?

Delphi XE


Это сообщение отредактировал(а) malor - 28.7.2011, 16:23

1. Действительно может быть меньше, потому что совсем не обязательно происходит реальная запись. Это же буфферизуется
2. Не используй Now. Еспользуй GetProcessTimes/GetThreadTimes

Для определения не очень больших интервалов времени всегда предпочитал использовать QueryPerformanceCounter. С GetProcessTimes/GetThreadTimes не работал. Есть уверенность, что эти функции действительно дадут обещанную в хелпе точность?

Точность - не то же самое, что аккуратность Нет уверенности. Но можно сделать побольше итераций и таким образом решить эту проблему.

А QueryPerformanceCounter, как и Now, как и GetTickCount бессильны в случаях когда в середине измеряемого интервала активизируетсмя какой-нить другой тред и начинает делать что-то тяжелое

Обоснуй! Про Now и GetTickCount я не спрашиваю. Только про QueryPerformanceCounter.

ну прогони вот такую прогу и посмотри на результат


у меня она выдала

Видно что результат прямопропорционален задержке в Sleep. Известно что эта функция делает вызвавший тред не планируемым как минимум на указанный интервал (ну есть неточность связанная с частотой таймера, но это в данном случае не важно). Большинство этого времени тред не выполняется. 
Представь что там не Sleep, а код, который ты пытаешься так профайлить. В середине этого кода, на на том же логическом процессоре начинает выполняться чужой поток (тз-за конца кванта времени отпущенного твоему потоку, или это высокоприоритетный поток и он вытесняет твой на этом основании). 
И QueryPerformanceCounter как ни в чем не бывало вернет тебе время, включающее выполнение чужого потока.

Наверно мы говорим о разном.
Ты уж тогда приведи пример использования функций GetProcessTimes/GetThreadTimes в тех же условиях. А я уж сравню результаты.

P.S. Но "логгирование" тут уж никак ни при чём.

Сейчас



А где о нем шла речь?

В "некромантском " посте от 28.7.2011, 16:22
на который вы "поспешили ответить" 17.10.2011, 22:45 

Как-то так

результат:


видим что в случае Sleep никакого выполнения не фиксируется, а в случае задержки циклом - фиксируется время, грубо пропорциональное времени задержки. То что грубо вина не только GetThreadTimes а еще и GetTickCount который тут постольку поскольку.

Добавлено через 1 минуту и 42 секунды
даже не представляю как я тут оказался 

А я ведь не об этом. То что GetTickCount имеет дискретность ~16мс это не секрет.
И прямая пропорциональность тоже не волшебство.
Я лишь хотел спросить о том, поддерживают ли функции GetProcessTimes/GetThreadTimes обещанную точность в 100 наносекунд?
Дело в том, что на предыдущей своей работе столкнулся с тем, что внешнее (и ну очень дорогое железо) никак не хочет принимать команды чаще чем через 16 мс. Но это бы ещё ничего. Но примерно раз через пять, оно принимало и выполняло команды с задержкой в 200-300 мс.
Только логгирование с помощью функции QueryPerformanceCounter мне помогло доказать начальству, что то железо, которое они купили за бешеные деньги ни как им не годится. 

Вот тут ты просил показать что QueryPerformanceCounter не выдерживает условия конкуренции тредов, а GetThreadTimes выдерживает. Я показал.
А твой пример со сторонним железом тут вообще не при чем, потому что не идет речь о том сколько же времени выполнялся код твоего процесса/потока, а только когда отреагировало железо.
Тут GetThreadTimes не поможет, но недостаток QueryPerformanceCounter остаётся: если твой тред вытеснят, то ты поставишь отметку времени завершения команды позже чем реально ответило железо.

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

P.S. Собственно к железу у меня претензий не было.
Дали бы мне "непосредственный" доступ к нему, я скорее всего смог бы с ним справиться так как нужно было заказчику. 

Ну собственно выполнение кода замерило бы, да.

Говорить о точности измерения временных интервалов в Винде - смех! Что  GetTick..., что Query..., что в стену - что об стену..

а что, профилировщики ещё не посоветовали?
лично я с делфи AQtime использую.