Timer vs. GetTickCount

[PSV]

Хаюшки!

В коде, написаном по мотивам http://www.smsoft.ru/ru/vbwait.htm, хотелось бы использовать для засечения ОЧЕНЬ коротких интервалов Timer (VB), а не возиться с GetTickCount (API). Достаточно разрешения системного таймера, но не меньше. Пробовал сравнивать Timer и GetTickCount - похоже обе используют системный таймер, с той лишь разницей что Timer генерирует нечто вида 0.0011782 с, тогда как GetTickCount при тех же условиях 0.001 c, 0.002 c и т.д.

Но на всякий случай хочется уточнить:
1. Timer и GetTickCount имеют одинаковую разрешающую способность, задаваемую системным таймером?
2. Не имеет ли применение Timer по сравнению GetTickCount каких либо недостатков в случае когда в комбинации c MsgWaitForMultipleObjects (API) требуется сделать ожидание в течении интервалов <100мс c реакцией на события.

P.S.
То что GetTickCount сбрасывается реже не имеет значения.

[tyomitch]

Пробовал сравнивать Timer и GetTickCount - похоже обе используют системный таймер, с той лишь разницей что Timer генерирует нечто вида 0.0011782 с, тогда как GetTickCount при тех же условиях 0.001 c, 0.002 c и т.д.

Но на всякий случай хочется уточнить:
1. Timer и GetTickCount имеют одинаковую разрешающую способность, задаваемую системным таймером?

Да (а именно 55мс)

2. Не имеет ли применение Timer по сравнению GetTickCount каких либо недостатков в случае когда в комбинации c MsgWaitForMultipleObjects (API) требуется сделать ожидание в течении интервалов <100мс c реакцией на события.

Недостаточно информации, чтобы решить. Какие именно "недостатки" тебя интересует, и что именно происходит в твоей проге?

[PSV]

Да (а именно 55мс)

Если верить MSDN по GetTickCount и GetSystemTimeAdjustment (API), то на PII400 под NT все таки не 55мс, а где то 10мс, хотя под Win9x ...

Недостаточно информации, чтобы решить. Какие именно "недостатки" тебя интересует, и что именно происходит в твоей проге?

Чаще всего при коммуникациях через COM-порт и через TCP-IP мне необходимо делать ожидание типа "пока не пришло...", "пока не отправлено..." при этом не прекращая обработку событий. Делать это через таймеры (OCX) не очень удобно. Поэтому я пользуюсь MsgWaitForMultipleObjects (API) почти так как это описано в http://www.smsoft.ru/ru/vbwait.htm

[PATRIOT_kz]

ХеХ.

Нашли что сравнить!
Лучше бы вы сравнивали коннекты!
Народная мудрость: "на медленной скорости, быстрая бошка,"
"а на высокой, фиг от моржа".

[GSerg]

Ну если всё требуется высокоточный таймер, то это queryperformancecounter.

[PSV]

Ну если всё требуется высокоточный таймер, то это queryperformancecounter.

В использовании мультимидийного таймер а необходимости пока нет (да и проблем с ним прибавится) - достаточно и системного тайиера, поэтому и вопрос только в различиях Timer и GetTickCount, если таковые есть. Что касается быстрой реакции MsgWaitForMultipleObjects итак выйдет из цикла ожидания при поступлении события и если данное событие будет по приему или отправке то реакция последует незамедлительно. Таким образом Timer и GetTickCount у меня используются для:
1. Отслеживания тайм-аутов (для COM-порта это обычно 500мс, для TCP-IP в условиях локалки еще не определился, но наверное не менее 100мс).
2. Задержек (для COM-порта это 100мс, для TCP-IP не нужны).

[tyomitch]

PSV, в таком случае разницы имхо нету. Померяй по скорости, что из них быстрее, - я думаю, Timer.

[PSV]

PSV, в таком случае разницы имхо нету. Померяй по скорости, что из них быстрее, - я думаю, Timer.

Ну вроде одинаковое быстродействие. Я вот только про другую весчь забыл - если MsgWaitForMultipleObjects вызовется после того как в очереди сообщений будет сообщение о том что байт пришел/байт отправлен она ж зараза в течении всего тайм-аута или до первого события ждать будет...

[tyomitch]

Ну так проверяй этот байт перед вызовом MsgWaitForMultipleObjects