Дело не в скорости, а в том как работает EventLoop.
setInterval ставит задачу в него безусловно, отработала текущая итерация или нет.
В результате, если выполняемая задача начинает есть больше времени чем период интервала (по разным причинам), то задачи в очереди начнут накапливаться. В результате браузеру будет некогда заниматься другими задачами, он будет тратить все свое время на обслуживание этого setInterval.
Обойти эту проблему помогает использование setTimeout, который планирует лишь одну, следующую, итерацию вычислений. В конце который вы снова вызываете setTimeout. Таким образом задача сама себя ставит в очередь. И в итоге, если она начинает тормозить, то и планировать себя она начинает медленнее, т.е. тормозит только эта подвисшая задача.
При использовании setInterval браузер может «зафризиться», при рекурсивном setTimeout — добиться этого гораздо сложнее.
И еще раз заострю внимание: время таймаута для следующей итерации нужно вычислять каждый раз через объект Date, т.к. JS вам не гарантирует точность тайминга асинхронных вызовов. Т.е. на одной итерации у вас будет 1000ms, на другой, может 950ms, а на третей может быть 1050ms.
Возможно, в вашем случае с аналоговыми часами это не страшно — позицию стрелок вы вычисляете используя Date, но если бы вы просто делали цифровые часы, используя таймеры, то они убегали бы или отставали в зависимости от загрузки процессора и других факторов.
setInterval — это очень плохая идея для продакшена. Лучше — вложенные setTimeout.
Но с часами отдельная история: если хочется попадать в секунды, то нужно каждый раз подстраивать время таймаута, т.к. из-за внутреннего устройства JS (EventLoop), таймер выполняется не точно в назначенное время, а где-то около него.
И еще, очень хочется демку, чтобы сразу поиграть с ней.
Спасибо Вам за статью. Я сам очень долго собираюсь, и никак не соберусь сделать летопись семьи. А время уходит…
Ваша статья придала мне заряд энтузиазма для этого дела.
А читать про очередной гаджет надоедает.
Intel заявляет, что можно будет не только использовать XPoint в качестве ОЗУ, но можно будет устанавливать их одновременно с обычными модулями памяти. Но есть подозрение, что работать это все будет на основе расширений протокола и в связке с новыми процессорами Intel. Надеюсь, все-же, что расширения будут открытыми.
Подскажите, пожалуйста, я не совсем понял.
В стандартной поставке Behave нет вообще никаких шагов, даже таких банальных как открыть URL и кликнуть элемент? Т.е. чтобы начать писать тесты на естественном языке, мы должны сначала сформировать словарь всевозможных шагов?
В копилку изоморфных фреймворков: CatBerry.
Из фишек, прогрессивный рендеринг — клиенту начинает отправляться html как можно быстрее. Таким образом браузер может уже работать с head, когда последний блок на странице еще не сгенерирован сервером. (Минус этой фичи: код ответа сервера всегда строго 200)
Заметьте, все самые гениальные идеи обычно зарисованы на каких-то немыслимых черновиках; на чем попало. Перенесешь потом на чистый аккуратный лист: вообще не то будет.
setInterval ставит задачу в него безусловно, отработала текущая итерация или нет.
В результате, если выполняемая задача начинает есть больше времени чем период интервала (по разным причинам), то задачи в очереди начнут накапливаться. В результате браузеру будет некогда заниматься другими задачами, он будет тратить все свое время на обслуживание этого setInterval.
Обойти эту проблему помогает использование setTimeout, который планирует лишь одну, следующую, итерацию вычислений. В конце который вы снова вызываете setTimeout. Таким образом задача сама себя ставит в очередь. И в итоге, если она начинает тормозить, то и планировать себя она начинает медленнее, т.е. тормозит только эта подвисшая задача.
При использовании setInterval браузер может «зафризиться», при рекурсивном setTimeout — добиться этого гораздо сложнее.
И еще раз заострю внимание: время таймаута для следующей итерации нужно вычислять каждый раз через объект Date, т.к. JS вам не гарантирует точность тайминга асинхронных вызовов. Т.е. на одной итерации у вас будет 1000ms, на другой, может 950ms, а на третей может быть 1050ms.
Возможно, в вашем случае с аналоговыми часами это не страшно — позицию стрелок вы вычисляете используя Date, но если бы вы просто делали цифровые часы, используя таймеры, то они убегали бы или отставали в зависимости от загрузки процессора и других факторов.
setInterval — это очень плохая идея для продакшена. Лучше — вложенные setTimeout.
Но с часами отдельная история: если хочется попадать в секунды, то нужно каждый раз подстраивать время таймаута, т.к. из-за внутреннего устройства JS (EventLoop), таймер выполняется не точно в назначенное время, а где-то около него.
И еще, очень хочется демку, чтобы сразу поиграть с ней.
Ваша статья придала мне заряд энтузиазма для этого дела.
А читать про очередной гаджет надоедает.
В данном руководстве автор рекомендует использовать для этой цели https://github.com/tj/n
В стандартной поставке Behave нет вообще никаких шагов, даже таких банальных как открыть URL и кликнуть элемент? Т.е. чтобы начать писать тесты на естественном языке, мы должны сначала сформировать словарь всевозможных шагов?
«Друг, какая у тебя система?»
Из фишек, прогрессивный рендеринг — клиенту начинает отправляться html как можно быстрее. Таким образом браузер может уже работать с head, когда последний блок на странице еще не сгенерирован сервером. (Минус этой фичи: код ответа сервера всегда строго 200)