Perché «manca 1 secondo» dura così tanto? — Come funzionano le barre di avanzamento e le stime di tempo

State guardando «manca 1 secondo» da 30 secondi. Proprio quando vi aspettate la fine, la scritta diventa «mancano 2 minuti».

Copie di file, installazioni di applicazioni, esportazioni video: le barre di avanzamento sono utili, ma a volte sembrano vivere in un mondo diverso da quello dell’orologio.

In realtà, una barra di avanzamento non è un orologio. La percentuale descrive quanto lavoro è stato completato; la stima di tempo prevede quanto potrebbe durare il lavoro restante; il completamento significa che le operazioni necessarie sono riuscite. Separare queste tre idee cambia il modo di leggere un lavoro che non finisce al 99%.

Questo articolo spiega i meccanismi generali usando la documentazione delle API e dell’interfaccia di Windows. Non ricostruisce l’algoritmo interno di una particolare versione di Esplora file. Gli esempi numerici e la demo di confronto usano carichi di lavoro fittizi, non misurazioni su un PC o su una connessione di rete.

1. Chiedetevi prima: 100% di che cosa?

Immaginate di rivedere 100 documenti. Se 99 sono brevi appunti e l’ultimo è un lungo contratto, «99 documenti completati» può essere corretto senza significare «è trascorso il 99% del tempo».

Anche un indicatore di avanzamento cambia significato a seconda del denominatore.

Per esempio, il callback di avanzamento usato dall’API di Windows CopyFileEx riceve la dimensione totale del file e i byte trasferiti. Questi descrivono lavoro, non secondi futuri. ¹

flowchart TB
    accTitle: Percentuale di avanzamento, tempo rimanente e completamento
    accDescr: Il diagramma separa un rapporto calcolato dal lavoro svolto, una stima di tempo basata su una velocità ipotizzata e un completamento stabilito da risultati riusciti.
    A["Lavoro svolto e lavoro totale"] --> B["Percentuale di avanzamento"]
    C["Lavoro restante e velocità prevista"] --> D["Tempo rimanente stimato"]
    E["Le operazioni necessarie riescono"] --> F["Lavoro complessivo completato"]

Figura 1: Un rapporto, una previsione e un risultato non sono tre nomi per la stessa informazione.

In tutto l’articolo, percentuale di avanzamento indica la frazione di lavoro misurabile completata, barra di avanzamento il suo indicatore visivo e tempo rimanente stimato la durata prevista. Non poter fare una previsione affidabile non cancella l’avanzamento già misurato.

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 9, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Come 10 secondi rimanenti diventano 79

La stima più semplice usa questa equazione:

Tempo rimanente ≈ lavoro restante ÷ velocità di elaborazione futura stimata

La parte difficile non è la divisione. È che la velocità futura non è ancora stata osservata. Usiamo quindi la velocità passata per prevederla. In una spiegazione del 2004 sulle stime dei tempi di copia, Raymond Chen di Microsoft descriveva proprio questa difficoltà di prevedere il futuro. Quell’articolo non è una specifica del calcolo usato nelle versioni odierne di Windows. ²

Considerate una copia fittizia di 1.000 MiB. Un MiB è 1.048.576 byte. Supponete che proceda dapprima a 80 MiB/s costanti per 2,5 secondi e poi rallenti a 10 MiB/s per il secondo successivo.

Il lavoro è avanzato durante quel secondo. Eppure la velocità stimata per il lavoro restante è scesa a un ottavo del valore precedente, quindi la durata prevista aumenta. Questo esempio usa direttamente la velocità dell’ultimo intervallo di osservazione.

flowchart TB
    accTitle: Perché il tempo rimanente può crescere mentre il lavoro avanza
    accDescr: Se la velocità prevista scende abbastanza, il suo effetto supera la riduzione del lavoro restante e il tempo rimanente calcolato aumenta.
    A["10 MiB completati in un secondo"] --> B["Resta meno lavoro"]
    C["La velocità prevista cala bruscamente"] --> D["Il tempo rimanente può aumentare"]
    B --> D

Figura 2: Un aumento della stima di tempo non significa che l’operazione sia andata indietro.

Lo stesso vale per «manca 1 secondo». Una quantità che alla velocità precedente richiederebbe un secondo richiederà di più se l’operazione successiva è più lenta. Anche gli intervalli di osservazione e gli arrotondamenti incidono sulla visualizzazione. Un numero che non cambia mai, però, non va dato per normale: distinguete, come vedremo, fasi di elaborazione, aggiornamenti dell’interfaccia e blocchi reali.

3. Fare una media renderebbe la stima esatta?

Riflettete ogni breve variazione di velocità e la stima salta su e giù. Usate solo la media dall’inizio e un periodo iniziale veloce può mantenere la stima ottimistica a lungo dopo un rallentamento prolungato.

Ciò deriva da come si combinano le osservazioni. Supponiamo di dare lo stesso peso a una velocità precedente di 80 e a una nuova di 10. La velocità prevista diventa 45. Cambia meno bruscamente di una stima basata solo sull’ultimo valore di 10, ma se la velocità resta davvero a 10 rimane ottimistica per un po’. Stabilità e reattività al cambiamento sono obiettivi diversi.

flowchart TB
    accTitle: Il compromesso nel lisciare le stime di velocità
    accDescr: Dare più peso alle osservazioni recenti rende la stima reattiva ma variabile, mentre dare più peso alla storia la rende più liscia ma più lenta ad adattarsi.
    A["Osservazioni di velocità"] --> B["Più peso ai dati recenti"]
    A --> C["Più peso alla storia"]
    B --> D["Reattiva ma variabile"]
    C --> E["Liscia ma più lenta ad adattarsi"]

Figura 3: Un numero che appare stabile non è necessariamente una previsione esatta.

Questo è un esempio per ragionare sulla stima, non la descrizione di un prodotto specifico. La mia raccomandazione progettuale è evitare di imporre un conto alla rovescia subito dopo l’avvio o un cambio di fase. Attendete osservazioni utili, poi presentate una stima come «circa un minuto». Dire che la stima è in fase di ricalcolo può essere meno fuorviante che mantenere un «manca 1 secondo» privo di fondamento.

4. 99 file completati, ma solo il 9,9% dei dati

Considerate ora l’unità conteggiata anziché la velocità. Ci sono 100 file: i primi 99 da 1 MiB ciascuno e l’ultimo da 901 MiB. Il totale è 1.000 MiB.

Dopo i primi 99 file, il numero di file dà 99 ÷ 100 = 99%. Il volume di dati dà 99 ÷ 1.000 = 9,9%. Resta un solo file, ma contiene il 90,1% dei dati. Entrambi i calcoli sono corretti: misurano cose diverse.

flowchart TB
    accTitle: Quando l'ultimo file è grande
    accDescr: Un grande file finale dopo 99 file piccoli fa divergere nettamente l'avanzamento per numero da quello per byte.
    A["99 file piccoli"] --> B["Quasi finito per numero di file"]
    C["Resta un file grande"] --> D["Resta gran parte dei dati"]
    B --> E["Viste diverse di un unico lavoro"]
    D --> E

Figura 4: Il 99% per numero di file non promette che resti solo l’1% del tempo.

Bastano allora i conteggi di byte? No. Trasferire molti file piccoli tramite SMB comporta ripetutamente il costo della creazione dei file e degli scambi di richieste. Lo stesso numero totale di byte non deve richiedere lo stesso tempo di un unico file grande. ³

Di conseguenza, «restano 500 MiB» può essere una misura esatta mentre il tempo necessario varia con il contenuto di quei 500 MiB. Mostrare sia i file sia i byte è utile non perché un numero sia sbagliato, ma perché ciascuno rivela ciò che l’altro tralascia.

5. «Preparazione» può significare: si sta cercando il denominatore

Una percentuale ha bisogno di un totale come denominatore. Ma chiedere a un’applicazione di elaborare un’intera cartella non significa necessariamente che abbia già enumerato ogni file al suo interno.

Supponete che l’applicazione creda che ci siano 100 elementi, ne elabori 80 e poi ne scopra altri 100. Quegli stessi 80 elementi completati rappresentano ora 80/200 anziché 80/100. La visualizzazione scende dall’80% al 40%, ma il lavoro svolto non è svanito. Presentare un totale provvisorio come definitivo ha creato lo scarto rispetto all’aspettativa di chi legge.

flowchart TB
    accTitle: Mostrare l'avanzamento prima che il totale sia noto
    accDescr: Mentre si stanno individuando gli obiettivi, evitate una percentuale definitiva; una volta noto il totale, combinatelo con il lavoro svolto per mostrare un rapporto.
    A["Individuare gli obiettivi"] --> B{"Il totale è noto?"}
    B -->|"Non ancora"| C["Mostrare fase e numero individuato"]
    B -->|"Sì"| D["Mostrare una percentuale"]

Figura 5: Un denominatore sconosciuto è diverso da uno 0% di avanzamento.

Windows offre controlli di avanzamento sia per valori determinati sia per attività indeterminate. ⁴ Per questa situazione consiglio di mostrare qualcosa come «Ricerca di elementi: 1.200 individuati» e poi una percentuale una volta noto il totale. L’assenza di un conto alla rovescia non è la prova che non stia accadendo nulla.

6. «Trasferimento 100%» e «tutto finito» segnano confini diversi

6.1 Alla fine può restare un’altra operazione

A titolo illustrativo, dividiamo il lavoro di un’applicazione in tre fasi: trasferimento, verifica e finalizzazione del risultato. Se la progettazione richiede una verifica dopo il trasferimento, il lavoro complessivo non è finito quando il trasferimento termina. È un esempio di progettazione applicativa, non l’affermazione che ogni copia o installazione segua queste fasi.

flowchart TB
    accTitle: Completamento del trasferimento contro completamento complessivo
    accDescr: Questa applicazione fittizia verifica e finalizza il risultato dopo il trasferimento, quindi i soli byte trasferiti non possono stabilire il successo complessivo.
    A["Trasferimento"] --> B["Verifica"] --> C["Finalizzare il risultato"] --> D["Successo complessivo"]
    A -.-> E["Il trasferimento al 100% finisce qui"]

Figura 6: Un ambito esplicito rende possibile spiegare perché dopo il 100% segua un’altra fase.

Anziché tenere una barra complessiva al 99% con «manca 1 secondo», è più coerente cambiare lo stato in «Trasferimento completato; verifica in corso». Anche le linee guida Microsoft per l’interfaccia delle applicazioni desktop sconsigliano di mostrare un completamento complessivo prima che l’operazione sia davvero terminata. ⁵

6.2 Anche le scritture hanno più di un confine

Windows di norma usa la memorizzazione nella cache per le scritture su file. A seconda delle impostazioni e dei contratti delle API, la scrittura dall’applicazione e il consolidamento dei dati sull’archiviazione riguardano confini diversi. ⁶ FlushFileBuffers è un’API per inviare al dispositivo le informazioni nel buffer di un determinato file. ⁷

flowchart TB
    accTitle: Una visione concettuale delle scritture nel buffer
    accDescr: Con il buffering, la scrittura accettata dall'applicazione e la successiva scrittura lato archiviazione non vanno trattate come lo stesso evento.
    A["L'applicazione scrive"] --> B["Trattenuto in un buffer"] --> C["Scritto sull'archiviazione"]

Figura 7: Questo è un diagramma concettuale delle scritture nel buffer, non il contratto di completamento di un singolo prodotto.

Tuttavia, una pausa al 99% non è sempre causata dallo svuotamento di una cache. Se il lavoro stia verificando, svuotando o attendendo altro va stabilito dalla sua progettazione o dalle sue registrazioni. Non deducete da un semplice numero di avanzamento che sia sicuro scollegare un dispositivo USB o togliere l’alimentazione.

7. Si è fermato il lavoro o solo la visualizzazione?

In un’applicazione WPF di Windows, il Dispatcher del thread di interfaccia elabora il lavoro dell’interfaccia. Occupare a lungo quel thread ritarda gli aggiornamenti e le risposte all’input. Distinguete l’operazione sottostante dal lavoro che ne porta i risultati sullo schermo. ⁸

flowchart TB
    accTitle: Il percorso dall'elaborazione alla visualizzazione dell'avanzamento
    accDescr: Anche se l'operazione segnala l'avanzamento, la visualizzazione non può rifletterlo finché l'interfaccia non elabora l'aggiornamento.
    A["Elaborazione effettiva"] --> B["Segnalare l'avanzamento"] --> C["Elaborare l'aggiornamento dell'interfaccia"] --> D["Aggiornare lo schermo"]
    E["Thread di interfaccia bloccato"] -.-> C

Figura 8: Una visualizzazione congelata non significa necessariamente che sia congelata l’operazione stessa.

Al contrario, un’animazione progettata per girare indipendentemente dal lavoro effettivo può continuare mentre quel lavoro attende. «Si muove quindi va bene; è ferma quindi è rotta» non è una distinzione sufficiente.

Consiglio di registrare prima la visualizzazione e l’ora di avvio, di controllare eventuali richieste in attesa di input e di confrontare conteggi o log nel tempo. Trattate le letture di Gestione attività come elementi di conferma. Prima di considerare la terminazione, verificate la procedura di annullamento dell’applicazione e che fine faccia l’output parziale.

Anche l’annullamento in .NET è cooperativo: richiedere l’annullamento non ferma di per sé l’operazione all’istante; l’operazione deve rispondere. ⁹ Per questo «annullamento in corso» e «annullato» dovrebbero essere stati distinti. Una sola visualizzazione di avanzamento non può fornire un numero universale di minuti dopo il quale forzare la chiusura dell’applicazione diventi sicuro.

8. Confrontare tre visualizzazioni della stessa operazione

Aprire la demo di confronto delle barre di avanzamento

La demo avanza fra le osservazioni di un carico di lavoro fittizio quando premete un pulsante. Non c’è bisogno di attendere e non legge, scrive o carica file. Il primo caso contiene 99 file piccoli e uno grande. Per ogni osservazione mostra affiancate una barra per numero di file, una per dati trasferiti e lo stato complessivo del lavoro.

Mentre viene trasferito l’ultimo file grande, la barra per numero resta al 99% anche se quella del volume di dati cresce. Quando i dati trasferiti raggiungono il 100%, lo stato complessivo è ancora «verifica in corso». Solo l’osservazione successiva segna il successo. Potete vedere come lo stesso lavoro possa sembrare fermo o attivo unicamente per il modo in cui è mostrato.

flowchart TB
    accTitle: Come leggere la demo di confronto
    accDescr: Una singola osservazione di un'operazione fittizia alimenta tre visualizzazioni: numero di file, dati trasferiti e stato complessivo.
    A["Un'operazione fittizia"] --> B["La stessa osservazione"]
    B --> C["Percentuale per numero di file"]
    B --> D["Percentuale per dati trasferiti"]
    B --> E["Stato complessivo del lavoro"]

Figura 9: La demo confronta tre viste di un’operazione, non tre operazioni diverse.

Il secondo caso riproduce il rallentamento della sezione 2 e mostra il calcolo che trasforma 10 secondi in 79. Usa il calcolo seguente. È una stima didattica volutamente semplice, non un’implementazione di produzione con ritentativi, elaborazione parallela o previsione per singola fase.

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

Usate unità coerenti per remaining e rate, per esempio MiB e MiB/s. Un valore restituito pari a zero significa che non resta nulla del carico di lavoro misurato, non che l’intero lavoro applicativo sia riuscito. Con lavoro restante positivo, una velocità pari a zero o sconosciuta produce null, così che una stima sconosciuta non venga scambiata per «mancano 0 secondi».

9. L’obiettivo è non fuorviare, non semplicemente sembrare precisi

Per la progettazione di cui si parla qui terrei separati la fase corrente, il lavoro misurato, una stima di tempo solo quando è giustificata e il risultato di successo, fallimento o annullamento. Anche combinando le percentuali delle fasi in un’unica barra, una ripartizione come «trasferimento 80%, verifica 20%» rappresenta pesi di progettazione, non una garanzia sulla distribuzione dei tempi di questa esecuzione.

flowchart TB
    accTitle: Costruire una visualizzazione dell'avanzamento a partire dalle osservazioni
    accDescr: Mostrate la fase corrente, le quantità misurate, una stima di tempo quando è giustificata e il risultato finale come informazioni separate.
    A["Informazioni dall'operazione"] --> B["Fase corrente"]
    A --> C["Lavoro misurato e totale"]
    A --> D["Stima quando è giustificata"]
    A --> E["Successo, fallimento o annullamento"]

Figura 10: Tenete distinte osservazioni e previsioni anche sullo schermo.

«Verifica: 400 / 1.000 elementi; calcolo del tempo rimanente» può essere utile senza conto alla rovescia. Se mostrate un orario, distinguete «ultimo aumento dell’avanzamento» da «ultima comunicazione riuscita con l’interfaccia». Non aggiornate solo il secondo in modo da far apparire normale un lavoro bloccato.

Lo stesso principio vale per l’accessibilità. L’elemento HTML progress può rappresentare un avanzamento indeterminato omettendo il proprio valore. ¹⁰ Per un indicatore di avanzamento ARIA personalizzato, omettete aria-valuenow quando il valore è sconosciuto e fornite un nome accessibile che identifichi che cosa sta avanzando. ¹¹ Sia la visualizzazione sia l’informazione letta ad alta voce devono riflettere onestamente ciò che è noto.

10. Domande frequenti

«Manca un secondo» senza completamento significa che qualcosa è fallito?

La sola visualizzazione non può deciderlo. Distinguete una stima inesatta, un’altra fase, aggiornamenti dell’interfaccia ritardati e un blocco reale. Sia «capita spesso, quindi va tutto bene» sia «è passato un secondo, quindi è rotto» saltano alle conclusioni.

Il 99% significa che resta l’1% del tempo totale?

No. Che la percentuale conti file o byte, il tempo per unità non deve essere costante. Moltiplicare il tempo trascorso per l’1% non dà la durata rimanente.

Un’animazione che gira significa che il lavoro procede bene?

Un indicatore di attività e una prova di avanzamento del lavoro sono cose diverse. Guardate insieme lavoro svolto, fasi e log. La sola animazione non garantisce che il lavoro possa arrivare a buon fine.

Posso mostrare l’avanzamento senza conoscere il tempo rimanente?

Se la quantità totale e quella completata sono note, potete mostrarne il rapporto. Omettete solo il conto alla rovescia quando la previsione non è affidabile. Quando il totale stesso è sconosciuto, usate un indicatore indeterminato con la fase e il numero di elementi completati.

11. Riepilogo: il tempo rimanente è una previsione, il completamento è un risultato

«Manca un secondo» non dura a lungo perché il computer non sappia contare fino a uno. Dura perché si usa il lavoro osservato per stimare un tempo di elaborazione che non è ancora avvenuto. Unità di conteggio, individuazione degli obiettivi, fasi finali e aggiornamenti ritardati dell’interfaccia aggiungono ulteriori complicazioni.

flowchart TB
    accTitle: Domande da porsi davanti a una visualizzazione di avanzamento che non finisce
    accDescr: Verificate che cosa misuri la percentuale, se la velocità prevista sia cambiata, se resti un'altra fase e se sia bloccata l'interfaccia o l'operazione effettiva.
    A["Percentuale di che cosa?"] --> B["La velocità prevista è cambiata?"] --> C["Resta un'altra fase?"] --> D["Blocco dell'interfaccia o dell'elaborazione?"]

Figura 11: Trasformate il fastidio per un numero in domande che potete indagare.

Come utenti, guardate fasi e cambiamenti anziché i soli numeri. Come sviluppatori, non mescolate lavoro misurato, previsione e risultati. Più importante che azzeccare ripetutamente «un secondo» è spiegare che cosa sta accadendo ora e che cosa è ancora sconosciuto. Questo è il compito di una buona visualizzazione dell’avanzamento.

Link di riferimento

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Un lavoro fermo a un secondo rimanente significa che qualcosa è fallito?

La sola visualizzazione non può dirvelo. Distinguete una stima di velocità inesatta, una fase di elaborazione finale, un'interfaccia ferma e un blocco reale. Controllate le variazioni di conteggi e log e cercate richieste in attesa di input. Non forzate la chiusura dell'applicazione solo perché indica un secondo rimanente.

Il 99% significa che resta solo l'1% del tempo totale?

No. Il significato dipende dal fatto che la percentuale misuri elementi, byte o fasi ponderate, e quelle unità non devono richiedere lo stesso tempo. Una percentuale di avanzamento misura una frazione di lavoro, non il tempo rimanente.

Un'animazione che gira dimostra che il lavoro procede bene?

No. Quando animazione ed elaborazione sono indipendenti, l'animazione può continuare mentre il lavoro attende. Distinguete l'animazione dalle prove di lavoro svolto, come conteggi, cambi di fase e log.

Posso mostrare una barra di avanzamento senza una stima di tempo affidabile?

Sì. Quando la quantità totale e quella completata sono note, potete mostrarne il rapporto e omettere la stima di tempo se la velocità è instabile. Quando il totale stesso è sconosciuto, mostrate la fase o il numero di elementi completati anziché inventare una percentuale.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.