Тема: AHK: Не корректная работа sleep
При выполнении sleep 100, 1100, 2100 и тд происходит задержка в 0.11 1.11 2.11 и тд, если поменять 100 на 99 то задержка составляет 0.9.
Как это исправить?
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
При выполнении sleep 100, 1100, 2100 и тд происходит задержка в 0.11 1.11 2.11 и тд, если поменять 100 на 99 то задержка составляет 0.9.
Как это исправить?
Это может быть связано с тем, что функция Sleep в AutoHotkey имеет ограничение точности до 10-15 миллисекунд. Поэтому задержки, указанные в 100, 1100 и 2100 миллисекундах, могут привести к некоторому округлению и неточности в результате.
Если вам нужно точное время задержки, вы можете использовать другие методы, например, функцию SetTimer с низким разрешением таймера или использовать библиотеки с высоким разрешением времени, такие как QueryPerformanceCounter.
Если точность не является критически важной, вы можете попробовать использовать более точный интервал задержки, например, 99 миллисекунд вместо 100 миллисекунд. Это может уменьшить ошибку округления и сделать вашу задержку более точной.
size222
Похоже на ответ из ChatGPT. Как использовать QueryPerformanceCounter вместо Sleep? Что за функция "SetTimer с низким разрешением таймера" и как её использовать вместо Sleep?
Если точность не является критически важной, вы можете попробовать использовать более точный интервал задержки
Какой смысл в этой фразе?
Можете в таком случае подсказать как через QueryPerformanceCounter реализовать альтернативу sleep потому что я не смог разобраться как он работает.
В идеале сразу готовый альтернативный код представленный коду ниже.
sendinput {a}
sleep 100
sendinput {b}
pwch, в AutoHotkey по умолчанию присутствуют всякие-разные встроенные задержки, которые первоначально не равны нулю, и их можно настраивать соответствующими командами:
SetKeyDelay
SetControlDelay
SetMouseDelay
SetWinDelay
SetBatchLines
Прочитайте соответствующие статьи в справке, уверен, много прояснится.
ypppu, боюсь, всё это не имеет отношения к вопросу.
Можете в таком случае подсказать как через QueryPerformanceCounter реализовать альтернативу sleep
Он не может. По всей вероятности, как я упомянул, этот текст сформирован ChatGPT.
Можно так попробовать:
SetBatchLines, -1
PS := new PreciseSleep
start := A_TickCount
PS.Sleep(1000)
end := A_TickCount - start
PS := ""
MsgBox, % end
class PreciseSleep {
__New(TimePeriod := 3) {
this.timePeriod := TimePeriod
DllCall("Winmm\timeBeginPeriod", "UInt", TimePeriod)
}
__Delete() {
DllCall("Winmm\timeEndPeriod", "UInt", this.timePeriod)
}
Sleep(ms) {
DllCall("Sleep", "UInt", ms)
}
}
Хотя у меня особой разницы в точности это не даёт.
Хотя у меня особой разницы в точности это не даёт.
На самом деле даёт, надо просто правильно замерять:
SetBatchLines, -1
DllCall("QueryPerformanceFrequency", "Int64P", frequency)
PS := new PreciseSleep()
DllCall("QueryPerformanceCounter", "Int64P", start1)
PS.Sleep(100)
DllCall("QueryPerformanceCounter", "Int64P", end1)
DllCall("QueryPerformanceCounter", "Int64P", start2)
PS.Sleep(1200)
DllCall("QueryPerformanceCounter", "Int64P", end2)
PS := ""
MsgBox, % (end1 - start1)/frequency * 1000 . "`n" . (end2 - start2)/frequency * 1000
class PreciseSleep {
__New(TimePeriod := 3) {
this.timePeriod := TimePeriod
DllCall("Winmm\timeBeginPeriod", "UInt", TimePeriod)
}
__Delete() {
DllCall("Winmm\timeEndPeriod", "UInt", this.timePeriod)
}
Sleep(ms) {
DllCall("Sleep", "UInt", ms)
}
}
Получается QueryPerformanceCounter точнее чем A_TickCount.
teadrinker
В коде uPeriod = 3, но погрешность на практике 1 мс, что то не работает.
https://learn.microsoft.com/en-us/windo … eginperiod
Установка более высокого разрешения может повысить точность интервалов времени ожидания в функциях ожидания. Однако это также может снизить общую производительность системы, поскольку планировщик потоков чаще переключает задачи.
Если настройка глобальная и не особо полезная, не лучше её сразу отключать?
Sleep(ms) {
DllCall("Winmm\timeBeginPeriod", "UInt", 3)
DllCall("Sleep", "UInt", ms)
DllCall("Winmm\timeEndPeriod", "UInt", 3)
}
погрешность на практике 1 мс, что то не работает.
А почему 1 не может быть?
MsgBox % mod(100, 3)
Ну и некоторая погрешность измерения возможно остаётся.
Если настройка глобальная и не особо полезная, не лучше её сразу отключать?
Так у меня иногда погрешность до 7 вырастает. Кроме того, такой Sleep чаще всего используется в цикле, чтобы получить минимальную, но не нулевую паузу. Если менять эту настройку каждые несколько милисекунд, возможно будет сказываться на производительности, и не сойдёт ли с ума компьютер? Кроме того,
Starting with Windows 10, version 2004, this function no longer affects global timer resolution.
MsgBox % mod(100, 3)
Убедил, просто у меня больше 1го не было.
Starting with Windows 10, version 2004, this function no longer affects global timer resolution.
То есть это настройка для текущего процесса? timeEndPeriod становится не нужен в контексте постоянной необходимости DllCall("Sleep", "UInt", ms)?
Почему не нужен, то, что ты процитировал выше, тоже верно, нагрузка на систему увеличивается.
Почему не нужен
А зачем нужен?
Чтобы снизить нагрузку на систему же.
Со стороны одного процесса?
А что тебя удивляет? Нагрузка не всегда исчерпывается отображаемым в Диспетчере задач процентом.
Ничего не удивляет, я спросил, ты говоришь про нагрузку со стороны одного процесса?
Точнее будет сказать, что нагрузка возникает из-за применения этой фичи.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться