Скрость программ!
Например есть две проги, делающие одно и тоже, и нужно определить какая из быстрее.;)
кроме шуток, можно определить приблизительно время выполнения (больше меньше) по количесву инстркций на asm'е - на которые транслируется твой код. делается енто через отладчик. А можно узнать зачем тебе это? не тормозит и ладно :angel:
Есть. Часы. Теоритически. Слабо на стрелочных (механических) часах с минутной и часовой стрелкой засечь у какого окна мессага быстрее вылезет? :D
кроме шуток, можно определить приблизительно время выполнения (больше меньше) по количесву инстркций на asm'е - на которые транслируется твой код. делается енто через отладчик. А можно узнать зачем тебе это? не тормозит и ладно :angel:
А если просто дизасемблировать программу и посчитать кол-во инструкций.
А если просто дизасемблировать программу и посчитать кол-во инструкций.
Ну извините, какой асм, какой отладчик!?!?!?!!!
Разные инструкции занимают разное время выполнения и разница тут не в 0.01 нано-сек. Есть инструкции, которые пачкой за 1 такт выполняются, а есть такие, которые за отпущенное операционкой (многозадачной) время не справляются: например, всякие stos, movs - инструкции для работы с массивами, или MMX инструкции.
А как же циклы, дальние переходы, вызовы функций??? В пару инструкций можно написать простейший цикл, который DOS повесит. Все ООП-шные проги тормозят из-за огромного числа дальних переходов (вызовы процедур).
Так что в одной проге может быть 1000 логических операций, но она будет в 1000 раз быстрее работать, чем другая прога, в которой 1000 дальних переходов в перемешку с циклами.
Ну и наконец, нормальные проги юзают всякие dll-ки и COM-объекты. Что ж, предложите дизассемблировать и все используемые дллки??
Чтоб замерить скорость достаточно часов. Если разница в скорости большая, то можно и обычными часами замерять. Если необходима большая точность, то теоретически, можно написать прогу-таймер, которая будет следить за текущими процессами и как только нужный процесс запустится - таймер включется, процесс завершился - таймер остановился. Можно как ни будь, опять же теоретически, отслеживать события, которые может генерить подопытная прога, ну и т.п.
Ну извините, какой асм, какой отладчик!?!?!?!!!
Разные инструкции занимают разное время выполнения и разница тут не в 0.01 нано-сек. Есть инструкции, которые пачкой за 1 такт выполняются, а есть такие, которые за отпущенное операционкой (многозадачной) время не справляются: например, всякие stos, movs - инструкции для работы с массивами, или MMX инструкции.
А как же циклы, дальние переходы, вызовы функций??? В пару инструкций можно написать простейший цикл, который DOS повесит. Все ООП-шные проги тормозят из-за огромного числа дальних переходов (вызовы процедур).
Так что в одной проге может быть 1000 логических операций, но она будет в 1000 раз быстрее работать, чем другая прога, в которой 1000 дальних переходов в перемешку с циклами.
Ну и наконец, нормальные проги юзают всякие dll-ки и COM-объекты. Что ж, предложите дизассемблировать и все используемые дллки??
Чтоб замерить скорость достаточно часов. Если разница в скорости большая, то можно и обычными часами замерять. Если необходима большая точность, то теоретически, можно написать прогу-таймер, которая будет следить за текущими процессами и как только нужный процесс запустится - таймер включется, процесс завершился - таймер остановился. Можно как ни будь, опять же теоретически, отслеживать события, которые может генерить подопытная прога, ну и т.п.
Стоп стоп, какие дизассемблеры, какие инструкции?
Для этих целей есть WinAPI. См. GetProcessTimes