Il problema con l'orologio - a se o non a se?

1. Considera la deriva, come menzionato da Mason Wheeler. Non incrementare ogni contatore, piuttosto aggiorna lo stato del clock direttamente.

   Non dare per scontato che ogni minuto abbia 60 secondi. Alcuni ne hanno 59, altri 61 . Se esegui ingenua matematica datetime, incapperai anche in problemi di fuso orario e di ora legale, o creerai nuovi bug <20> Y2K Y2038. La maggior parte delle lingue ha solide librerie datetime, li usano invece per determinare l'ora effettiva.

2. L'aggiornamento di tre lancette dell'orologio non è necessariamente significativamente più costoso dell'aggiornamento. Se gli aggiornamenti sono costosi, uno di solito si disegna su un buffer fuori campo e si aggiorna una sola volta (spesso questa tecnica consente anche animazioni più fluide). Nota: aggiornamento ≠ disegno.

   Considera anche che ogni aggiornamento può causare un nuovo disegno dell'intera immagine. Se la lancetta dell'orologio spostato copre una parte di un'altra, allora la mano sotto dovrà essere ridisegnata comunque. Se più livelli sono composti su un altro, allora il tuo codice potrebbe non rendersene conto, ma si verificherà ancora un ridisegno: l'immagine finale è (presumibilmente) solo un buffer di byte.

Tutto sommato, mi oppongo con veemenza contro il tentativo di salvare alcuni cicli prendendo le scorciatoie errate . Sì, un buon programmatore proverà a scrivere codice efficiente, ma questo è un meraviglioso esempio di come l'ottimizzazione prematura può essere malvagia .

Quindi se e solo se è valido prendere la scorciatoia di solo disegnare gli aggiornamenti quando necessario, quindi per favore fallo. Altrimenti, usa la variante presumibilmente inefficiente (congettura: non è quella cattiva), o trova altri modi per ottimizzare.

L'efficienza è importante, ma la precisione è ancora più importante. Ecco perché un buon orologio JavaScript farà esattamente quello che stai descrivendo.

Funziona in questo modo:

function update_clock
  Update current time (completely)
  set a timer to come back 1 second later and call update_clock

Potrebbe sembrare eccessivo, ma ricorda che i timer non sono accurati al 100%. Se torna 1,01 secondi dopo invece di 1 secondo dopo, il tuo orologio può iniziare a muoversi, il che significa semplicemente aggiungere 1 al valore dei secondi non è abbastanza buono. Inoltre, in questo modo può essere fatto con un solo timer, invece di averne bisogno due o tre.

Inoltre, supponiamo che qualcuno stia visualizzando una pagina Web, quindi mettono in pausa il sistema per alcune ore e lo riavviano. Se lo script dell'orologio risincronizza correttamente ogni secondo, ciò non causerà alcun problema tecnico; l'orologio si risincronizza solo contro l'orologio di sistema. Questo tentativo potrebbe essere rovinato da tentativi più folli.

Ricorda che la correttezza è quasi sempre più importante dell'efficienza, specialmente quando non causa effettivamente un collo di bottiglia nelle prestazioni nel tuo codice.

doTick() {
    second++;
    if ( (second % 60) == 0 ) {
        minute++;
        second = 0;
        if ( (minute % 60) == 0 ) {
            hour++;
            minute = 0;
            if ( (hour % 24) == 0 ) {
                day++;
                hour = 0;
            }
        } // end 60 minute check
    } // end 60 second check
} // end doTick()

Nessun controllo o incremento non necessario.

Tuttavia, se desideri un tempo preciso, utilizza l' oggetto Date JavaScript (presumendo che tu stia utilizzando JavaScript). Come ha detto un altro commentatore, nel mondo reale non puoi generalmente fare affidamento su qualcosa che chiama la tua funzione esattamente ogni secondo.