+ Дальнейшие копания привели вот к чему.

Process, Priority, , Realtime
SetBatchLines, -1

SetTimer, MyLabel, 94
SetTimer, MyLabel, OFF
DllCall("QueryPerformanceFrequency", "Int64*", Frequency)
Return

Lbutton::
N :=
t1 := A_tickcount
DllCall("QueryPerformanceCounter", "Int64*", CounterBefore)
SetTimer, MyLabel, ON
Return

MyLabel:
if (A_tickcount > t1 + (1000 * 60))
    {
    SetTimer, MyLabel, OFF
    ToolTip, % N . " щелчков за " t2 - t1 . " мсек `r`n" . 60*N/((t2 - t1)/1000) 
    . " щелчков за минуту `r`n" . (CounterAfter - CounterBefore)/Frequency . " точное время  `r`n"
    . PeriodMax . " <-------> " . PeriodMin
    Return
    }
;Click
N ++
t2 := A_tickcount
CounterAfterOld := CounterAfter
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)

Period :=(CounterAfter - CounterAfterOld)/Frequency
PeriodMin := !PeriodMin ? 0.1 : PeriodMin > Period ? Period : PeriodMin
PeriodMax := !PeriodMax ? 0.1 : PeriodMax < Period ? Period : PeriodMax

Return

Что это,как этим пользоваться? У меня рабоет - никак...

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

Действительно дает требуемое количество. Более того, не удалось воспроизвести ситуацию с лишним или недостающим кликом. То есть независимо от общего периода и прочих пришедших на ум условий. Почему у меня раньше были абсолютно другие результаты - ума не дам. Единственная разница - сейчас прописал в скрипт, а тогда нажимал вручную (может тачпад и его дрова?...).
Дальнейшие копания привели вот к чему.

Process, Priority, , Realtime
SetBatchLines, -1

SetTimer, MyLabel, 94
SetTimer, MyLabel, OFF
DllCall("QueryPerformanceFrequency", "Int64*", Frequency)
Return

Lbutton::
N :=
t1 := A_tickcount
DllCall("QueryPerformanceCounter", "Int64*", CounterBefore)
SetTimer, MyLabel, ON
Return

MyLabel:
if (A_tickcount > t1 + (1000 * 60))
    {
    SetTimer, MyLabel, OFF
    ToolTip, % N . " щелчков за " t2 - t1 . " мсек `r`n" . 60*N/((t2 - t1)/1000) 
    . " щелчков за минуту `r`n" . (CounterAfter - CounterBefore)/Frequency . " точное время  `r`n"
    . PeriodMax . " <-------> " . PeriodMin
    Return
    }
;Click
N ++
t2 := A_tickcount
CounterAfterOld := CounterAfter
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)

Period :=(CounterAfter - CounterAfterOld)/Frequency
PeriodMin := !PeriodMin ? 0.1 : PeriodMin > Period ? Period : PeriodMin
PeriodMax := !PeriodMax ? 0.1 : PeriodMax < Period ? Period : PeriodMax

Return

У меня дает реальную продолжительность периодов в пределах от 85 до 116 мс. Если большие периоды можно объяснить нагрузкой, то откуда меньшие?

В моём варианте 1 клик происходит каждые 100 мс. Если бы я задал 100, то число кликов начало бы отставать (точная причина мне неизвестна). Но я задал 94, чем компенсировал отставание. Теперь за минуту получается ровно 600 кликов.

Я запускал Ваш скрипт и ни разу не видел 600 в минуту. Может как раз у вас квант 10?
Если не затруднит, запустите у себя в таком виде и напишите, что отображается в тултипе:

Process, Priority, , Realtime
SetBatchLines, -1

SetTimer, MyLabel, 94
SetTimer, MyLabel, OFF
Return

~Lbutton::
N :=
t1 := A_tickcount
SetTimer, MyLabel, ON
Return

~Lbutton Up::
SetTimer, MyLabel, OFF
t2 := A_tickcount
ToolTip, % N . " щелчков за " t2 - t1 . " мсек `r`n" . 60*N/((t2 - t1)/1000) . " щелчков за минуту"
Return

MyLabel:
ToolTip % A_tickcount - t3
t3 := A_tickcount
Click
N ++
Return

У меня чередуются 94 и 109 (все из-за той же дробной части как я понимаю).
Потом попробуйте менять 94 на единицу в меньшую сторону, а затем в большую. В моем случае 93 и ниже до 79 включительно дает чередование 93/94, 95 и выше до 109 включительно дает 109/110. После преодоления этих порогов значение изменяется на 15 и т.д.

Кстати, в моей подпрограмме таймера просто щелчок ЛКМ и и увеличение переменной N на единицу. Возможно, это гораздо быстрее, чем прорисовать ToolTip.

Ну так речь идёт про алгоритм выполнения действий через определённый отрезок времени, который не надо под каждый случай и пк подгонять. И если он не в состоянии вовремя отобразить тултип, или как в приведённой теме перерисовать часы (там кстати как раз 1000мс, и очень быстро становится видно что секунды сбиваются), то зачем использовать такой алгоритм, когда есть уже простое решение?

Кстати, в моей подпрограмме таймера просто щелчок ЛКМ и и увеличение переменной N на единицу. Возможно, это гораздо быстрее, чем прорисовать ToolTip.

Не понял смысл теста.

Если действие выполняется ровно каждые 100мс, то при старте мы увидим ну например 648 и далее должно быть 748, 848 и.т.д. Ок, первую цифру в учёт не берём и наблюдаем за 48. Пускай будет всегда плюс потом минус примерно 10 или даже 20 мс. Но по вашей теории, постоянно должно быть рядом с ~50. А на практике будет только смещение вперёд или назад.
Нельзя подобрать заранее точную задержку (тем более понимая, что в очередь команд (для процессора) процесса даже с высоким приоритетом, может всегда вмешатся система или такой же приоритетный процесс, что неминуемо приводит к увеличению времени исполнения), её нужно постоянно корректировать, и никакой дллкэлл или вычисления квантов тут не помогут, имхо конечно.

Ну и для наглядности теста, конечно нужно увеличить задержку до 300~500 мс.

Простейший тест:

settimer, proc, 90
return

proc:
tooltip, % a_msec
return

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

Не понял смысл теста.

В моём варианте 1 клик происходит каждые 100 мс. Если бы я задал 100, то число кликов начало бы отставать (точная причина мне неизвестна). Но я задал 94, чем компенсировал отставание. Теперь за минуту получается ровно 600 кликов.

А чем мой вариант не устраивает? Как при бездействии, так и при 100% загрузке  процессора один-в-один укладывается.

В Вашем варианте 1 клик происходит каждые 94 мс, то есть с 17-го клика пойдет накапливаемое расхождение с требуемым количеством.
А 94 - не потому, что Ваш компьютер "съедает" 6 мс, а потому что 94 это близко к значению, кратному 15,6 мс. Именно квантом 15,6, как я понимаю, у всех отписавшихся оперирует система (в справке сказано - зависит от железа и дров). Поэтому задание временных параметров что для Sleep, что для SetTimer в промежутках между значениями, кратными 15,6 мс, по большому счету бессмысленно. 94 - как раз пороговое значение, при 95 фактический период становится близким 109 (при прогоне подряд меняется на единицу - видимо из-за дробной части у кванта). Такое же квантование и для A_tickcount, в чем нетрудно убедиться, замеряя время очень быстро выполняемых операций в цикле.