Moin Gunnar,
Hypothetische Annahme: Es gibt sinnvolle Anwendungen. ;-)
okay, mal angenommen. ;-)
function foo() {
refreshDisplay();
window.setTimeout("foo()", 1000);
}
>
> braucht ja zum Ausführen von `refreshDisplay()`{:.language-javascript} etwas Zeit, sagen wir 42 ms. Der Aufruf von `foo()`{:.language-javascript} – die Aktualisierung der Zeitanzeige – ist also nicht jede Sekunde, sondern alle 1042 ms.
In solchen Fällen tendiere ich dazu, den neuen Aufruf der Funktion schon zu "bestellen", bevor ich die eigentliche Arbeit erledige:
> ~~~javascript
function foo() {
> window.setTimeout("foo()", 1000);
> refreshDisplay();
> }
So geht der Zeitbedarf von refreshDisplay() nicht mehr in die Intervallzeit ein. In der wirklichen Welt muss man dann auf mögliche Rekursionen achten; u.U. hat es böse Folgen, wenn die Funktion "sich selbst überholt". Ob das im Zusammenhang mit setTimeout() in einer Browserumgebung auch problematisch ist, weiß ich nicht; ich vermute nein.
Das ändert aber nichts daran, dass ein Browser nun mal keine typische Echtzeitanwendung ist und somit schon vom OS kein garantiertes Zeitverhalten für sich beanspruchen kann. Browserinterne Scripts können sich also noch weniger darauf verlassen, dass Timerfunktionen pünktlich aufgerufen werden. Bei hoher Systemauslastung kann es schon mal sein, dass sich der Aufruf um ein paar Sekunden verspätet.
Daher erscheint es mir müßig, solche Zeitanzeige-Scripts nur der flüssigen Anzeige wegen auf eine Zehntelsekunde oder noch besser zu optimieren.
Schönen Tag noch,
Martin