fonction récursive vs setInterval vs javascript setTimeout

Comme déjà mentionné, d'innombrables fonctions récursives conduire à un débordement de pile. Temps, a conduit à des rappels seront exécutés dans un contexte particulier, avec un clair de la pile.

setInterval est utile pour les plus précis périodique appels récursifs setTimeout, cependant, il ya un inconvénient: Le rappel sera déclenché même si une exception non interceptée a été jeté. Ce produit généralement un plusieurs octets d'entrée de journal tous les 60 millisecondes, 1'440'000 entrées par jour. En outre, un setInterval de rappel avec charge lourde pourrait finir par avoir un script ne répond pas ou même système trou.

Récursive setTimeout immédiate avant le retour de fonction pas être exécuté si aucune exception n'a pas été pris. Il va garantir un laps de temps pour d'autres tâches après le retour de la fonction de rappel indépendante de la fonction du temps d'exécution.

En supposant que la "performance retard" décrit par Jan Juna, j'ai essayé ce script simple pour vérifier si il y a des différences en termes de débit:

Intervalle:

const max = 50;
const timer = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30, 40, 50, 100, 150, 200, 250, 300, 400, 500];

function crono(timer) {
  return new Promise(resolve => {
    const exit = [];
    let i = 0
    setInterval(() => i++, timer);

    setInterval(() => {
      exit.push(i);
      i = 0;
      if (exit.length === max) {
        const sum = exit.reduce((a, b) => (a + b), 0);
        const avg = sum / exit.length;
        console.log(`${timer} = ${avg}`);
        resolve(avg)
      }
    }, 1000);
  });
}

Promise.all(timer.map(crono)).then(process.exit);

Délai d'attente:

const max = 50;
const timer = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30, 40, 50, 100, 150, 200, 250, 300, 400, 500];

function crono(timer) {
  return new Promise(resolve => {
    const exit = [];
    let i = 0

    const redo = () => {
      i++
      setTimeout(redo, timer);
    }

    setInterval(() => {
      exit.push(i);
      i = 0;
      if (exit.length === max) {
        const sum = exit.reduce((a, b) => (a + b), 0);
        const avg = sum / exit.length;
        console.log(`${timer} = ${avg}`);
        resolve(x)
      }
    }, 1000);

    redo();
  });
}

Promise.all(timer.map(crono)).then(process.exit);

Et c'est la sortie vith nodejs 8.11: qui ne montre pas de différence en termes de débit:

Récursive setTimeout garantit un délai entre les exécutions, setInterval – ne.

Nous allons comparer les deux fragments de code. La première utilise l' setInterval:

let i = 1;
setInterval(function() {
  func(i);
}, 100);

Le second utilise récursive setTimeout:

let i = 1;
setTimeout(function run() {
  func(i);
  setTimeout(run, 100);
}, 100);

Pour setInterval le programmateur interne fonctionnera func(i) toutes les 100ms.

Le réel retard entre func appels pour setInterval est moindre que dans le code!

Qui est normal, parce que le temps pris par les func's exécution “consomme” une partie de l'intervalle.

Il est possible que func's exécution s'avère plus long que prévu et prend plus de 100ms.

Dans ce cas, le moteur s'attend func terminer, puis vérifie le planificateur et si le temps est écoulé, l'exécute à nouveau immédiatement.

Dans le cas limite, si la fonction s'exécute toujours plus de delay ms, puis les appels ne se fera sans une pause.

Le récursive setTimeout garantit le fixe delay (ici 100ms).