Здравствуйте, vdimas, Вы писали:

V>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера.

В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.

V>В общем, первый способ имеет низкую разрешающую способность, но дешевый.
V>Второй способ имеет лучшую разрешающую способность, но дорогой. ))

В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит. А MSR обновляется сам, всегда.
Такое поведение в абсолютном большинстве случаев. Иное — если недоступна RDTSC, то такого на практике под виндой ни у кого пока не было (ни у кого из миллиардов пользователей). Иное поведение может быть, если винда принудительно настроена на использование HPET.
Если недоступна HPET и RDTS, то будет использован тот же таймер что ты предлагаешь, с соответствующей точностью.

Здравствуйте, vdimas, Вы писали:

V>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера.

В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.

V>В общем, первый способ имеет низкую разрешающую способность, но дешевый.
V>Второй способ имеет лучшую разрешающую способность, но дорогой. ))

В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит. А MSR обновляется сам, всегда.
Такое поведение в абсолютном большинстве случаев. Иное — если недоступна RDTSC, то такого на практике под виндой ни у кого пока не было (ни у кого из миллиардов пользователей). Иное поведение может быть, если винда принудительно настроена на использование HPET.
Если недоступны HPET и RDTS, то будет использован тот же таймер что ты предлагаешь, с соответствующей точностью.