È 'pigro' il termine corretto per saltare in base al timestamp? [chiuso]

Naviga le tue risposte
-1

(1)

  • La vecchia utility make esamina i timestamp e, se l'output è più recente dell'input, salta (inutile, dispendiosa in termini di tempo) la ricompilazione di ad es. File C.
  • Lo stesso vale per molte lingue e compilatori. La generazione di miniature "pigro" nelle applicazioni Web salta quei pollici che sono più recenti dell'immagine di origine.
  • Gli strumenti di sincronizzazione file "intelligenti" fanno lo stesso, osservando i timestamp, per ridurre il volume di trasferimento.

Mi riferivo a questo come "pigro" . Tuttavia, guardando le citazioni sul web, il termine "pigro" in Informatica sembra davvero significare qualcosa di diverso: "fai qualcosa il più tardi possibile".

  • carica solo quella parte aggiuntiva quando è necessario
  • inizializza pigramente, ovvero al più tardi quanto necessario
  • valuta solo quella parte dell'equazione, quando ci arrivi ...

Quindi il mio termine è sbagliato? E quale sarebbe più corretto, per tutte le ottimizzazioni skip "is-newer-based"?

    
posta Frank Nocke 12.09.2014 - 10:46
fonte

2 risposte

2

Sì, make è pigro. Evita di fare un lavoro che è determinato non è necessario fare.

Da pagina di Wikipedia su valutazione pigra (l'enfasi aggiunta è mia):

lazy evaluation, or call-by-need is an evaluation strategy which delays the evaluation of an expression until its value is needed (non-strict evaluation) and which also avoids repeated evaluations

Rieseguire i passaggi (compilatori, linker, caricatori, preprocessori o qualsiasi altra cosa) che hanno già determinato di essere adeguatamente gestiti è una chiara "valutazione ripetuta". L'intero punto del Makefile è di specificare le dipendenze e determinare ciò che costituisce una valutazione necessaria o superflua.

È anche corretto chiamarlo "incrementale", "just-in-time" o "on-demand". Ma è anche, molto di design, pigro.

    
risposta data 12.09.2014 - 15:03
fonte
3

"Pigro" di solito significa rimandare le cose fino all'ultimo momento possibile, ad es. inizializzando un modulo solo quando è effettivamente necessario o calcolando solo tanti numeri di una sequenza infinita come l'utente effettivamente legge. I termini alternativi sono "just-in-time" o "on-demand".

Il concetto chiave qui è che questa è solo una buona idea se non sai esattamente cosa farà il programma in fase di runtime. In pratica ciò significa che è appropriato per i sistemi interattivi che dipendono da un flusso di input dell'utente. Se sapessi esattamente che un modulo sarà sempre usato, potresti anche inizializzarlo all'avvio, perché è più facile codificarlo e non fa aspettare l'utente più tardi quando sono in pieno recupero - modalità fatta di cose.

Non ripetere le compilation, come fa make , non è davvero paragonabile. Innanzitutto, qualunque cosa tu voglia venga sicuramente sarà ricercata - non c'è nulla nel set di regole che può essere o non essere necessario. Dopo aver assegnato un obiettivo a make , sai che tutte le precondizioni dovranno essere soddisfatte. E non importa quanto tu aspetti, il file sorgente sta per invecchiare, quindi la compilazione diventerà sempre meno necessaria, per così dire.

Quindi non hai funzioni interattive e sai esattamente cosa è e cosa non è necessario fare (perché questa è una specie di descrizione del lavoro di make . Perciò, direi che non si ripetono compilazioni inutilmente è solo un'istanza di caching giudizioso - anche una pratica diffusa, solo un po 'diversa.

    
risposta data 12.09.2014 - 10:55
fonte

Leggi altre domande sui tag

Con quale frequenza si dovrebbe salvare su disco un editor di testo che salva automaticamente? [chiuso] Quanto dureranno le riunioni di mischia? [duplicare]