Как браузеры определяют, какое время setInterval должен использовать?

Я думаю, во-первых, мы должны спросить себя, что мы ожидаем от интервальных функций:

• они должны поддерживать контекст: интервал, в котором вы не могли бы увеличить счетчик надежно, был бы довольно катастрофическим

• они должны выполнять все, что находится в функции, которая имеет приоритет над интервалом выполнения (то же самое здесь, что таймер должен подняться, прежде чем мы снова увеличим)

• он должен быть отделите стек выполнения от остальной части нашего кода js (мы не хотим ждать, пока эти таймеры закончат свой бизнес, пока остальные не начнут выполняться);

• они должны знать о контексте, в котором они находятся, независимо от того, насколько он огромен (мы хотим иметь возможность использовать jQuery внутри наших функций таймера, например).

так как Мэтт Грир сказал выше, интервалы по дизайну не точны, и это в основном потому, что мы на самом деле не ожидайте, что они будут точными, но будут надежно выполнять код в данный момент времени.

если вы посмотрите на реализацию Chromium, вы увидите, что реализация setTimeout и setInterval основана на DOMTimer::установить, который получает переданный контекст выполнения, действие и если таймер является одним выстрелом

это передается RunloopTimer, который выполняет цикл с помощью системных таймеров (как вы видите здесь)

(кстати, chromium устанавливает минимум 10 мс для интервала, как вы можете видеть здесь)

каждое выполнение действия обрабатывается здесь, который не делает никакого утверждения за время, прошедшее с момента последнего выполнения, превышающего или под определенным лимитом времени.

напротив, он только утверждает, что уровень вложенности таймера не слишком глубокий, замедляя таймеры, которые используют слишком много ресурсов / работает слишком медленно для данного интервала с этого:

if (m_nestingLevel >= maxTimerNestingLevel)
            augmentRepeatInterval(minimumInterval - repeatInterval());
    }

augmentRepeatInterval просто добавляет больше миллисекунд к интервалу:

void augmentRepeatInterval(double delta) { augmentFireInterval(delta); m_repeatInterval += delta; }

Итак, что мы можем заключить?

• измерять точность времени интервалов или таймаутов пустая трата времени. То, что вы должны и можете заботиться о том, что вы не устанавливаете слишком низкие интервалы для вещей, которые вы хотите выполнить в функции. Броузер сделает все возможное, чтобы выполнить ваши интервалы и таймауты своевременно, но это не гарантирует точное время.

• выполнение интервала зависит от среды, браузера, реализации, версии, контекста, самого действия и так далее и так далее. Это не должно быть точным, и если вы хотите запрограммировать что-то точное с помощью setTimeout или setInterval, вы либо сошли с ума сейчас, либо сойдете с ума позже.

• Вы сказали что в вашем коде, когда вы добавили тяжелое выполнение функций, таймер стал более точным. Это может быть по разным причинам (возможно, он получает больше памяти, более эксклюзивное время процессора, больше рабочих и так далее). Меня это очень интересует, но вы еще не предоставили код, который сделал тяжелое выполнение. Поэтому, если вы хотите получить ответы на этот вопрос, пожалуйста, предоставьте код, потому что без него трудно что-либо предположить.

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

обновление

кроме этого, код, который ни к чему не приводит, может быть также оптимизирован (не выполнен, выполнен только один раз, выполнен лучшим образом) браузером JS engine. Позвольте мне привести пример, основанный на вашем (все вещи, выполненные в chromium):

function start() {
  window.setInterval(function() {
    update();
  }, 1);
}

lastTime = new Date;
 numFrames = 0;
lastFrames = 0;

function update() {
  console.log(new Date() - lastTime);
  lastTime = new Date();
  for (var i=0; i < 1000000; i++) { var k = 'string' + 'string' + 'string' }
}

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

давайте посмотрим, как он изменяется, если выполнение должно поддерживать привязку к внешней переменной (kв этом case):

var k;

function update() {
  console.log(new Date() - lastTime);
  lastTime = new Date();
  for (var i=0; i < 1000000; i++) { k = 'string' + 'string' + 'string' }
}

ок, здесь мы имеем некоторое влияние на время выполнения, но это все еще довольно быстро. Браузер знает, что цикл всегда будет делать то же самое, но он выполняет его один раз. Ну и что, если итерация действительно создает огромную строку, например?

var k;

function update() {
  console.log(new Date() - lastTime);
  lastTime = new Date();
  k = '';
  for (var i=0; i < 1000000; i++) { k += i.toString() }
}

это ставит браузер в мир боли, потому что он должен вернуть эту строку из миллионов символов. Можем ли мы сделать это более болезненным?

var k;

function update() {
  console.log(new Date() - lastTime);
  lastTime = new Date();
  k = '';
  for (var i=0; i < 1000000; i++) { k = ['hey', 'hey', 'hey'].join('') }
}

эта конкатенация массива не может оптимизироваться и будет душить практически любой браузер медленно и болезненно.

таким образом, в вашем случае тяжелое выполнение может привести к резервированию и мгновенному освобождению оптимизатором большего объема памяти. Может быть, глоток свежего воздуха, дополнительная память и бездействующий процессор заставили вашу функцию прыгать от радости, но, как я уже сказал, Нет ничего надежного, не посмотрев на ваш тяжелый код выполнения.