La visualizzazione di una barra di avanzamento determina tempi di completamento più lenti
Scrivo molti script interni che automatizzano le attività per un team. Per evitare che si chiedano se lo script si è "fermato", visualizzo una semplice barra di avanzamento per le attività a lunga esecuzione. Lo faccio perché posso misurare l'importo completato poiché conosco l'importo che richiede il completamento prima dell'esecuzione. Per risparmiare sul numero di operazioni che vengono eseguite, aggiorno la barra di avanzamento solo ogni n
secondo o quando l'attività viene avviata / completata.
Quello che ho scoperto è che c'è un compromesso tra:
- esperienza utente (sapere che l'attività è in esecuzione)
- tempo di completamento della sceneggiatura generale
Aggiungendo passaggi per produrre una barra di avanzamento e tenerli al corrente, un'attività può richiedere il doppio del tempo.
In generale, è questo un compromesso previsto (forse non in altri linguaggi, ma in Python)?
Risposte
È una domanda molto carina.
In generale, diamo sempre la priorità all'esperienza utente.
Esempio: i motori di ricerca dei voli potrebbero fornire risultati istantaneamente ma hanno un caricamento più lungo poiché gli utenti si sentono più sicuri di aver effettuato una ricerca approfondita.
Quando si tratta di 2x volte più lento. 2x è probabilmente ok quando è un paio di secondi e probabilmente è terribile se è per anni. Tutto dipende dal contesto dei tuoi utenti. Se il tipo di lavoro del tuo sito è una questione di vita o di morte, più veloce è meglio, se i tuoi utenti sono più rilassati con il tempo necessario ed è più importante per loro sapere quando ricontrollare, quindi dire loro il tempo previsto sarebbe L'opzione migliore.
Rendilo più veloce quando
- È stato dimostrato che il tempo di caricamento ha un impatto negativo su adozione, utilizzo, affidabilità, fiducia, ecc.
- La velocità è una questione di vita o di morte
- La velocità è una questione di guadagno (ad esempio, i clienti al telefono hanno bisogno di una risposta urgente)
Mostra la barra di caricamento se
- Moltiplicando il tempo per due non si crea un tempo che scoraggerebbe completamente gli utenti
- Voi utenti potete permettervi di aspettare mentre probabilmente fate qualcos'altro
Altre cose da prendere in considerazione Forse hai bisogno di una soluzione ibrida che per alcuni processi ottieni la barra di caricamento e per altri no.
Forse hai bisogno di opzioni alternative: ad esempio mostrare la barra di caricamento e dire agli utenti che nascondendola possono velocizzare l'attività, chiedendo agli utenti se vogliono ricevere una notifica e-mail quando l'attività è pronta, ecc.
In ogni caso, l'idea migliore sarebbe vedere cosa preferirebbero gli utenti in base al loro contesto e alle loro esigenze.
Buona fortuna però, è una sfida molto interessante. Riporta la decisione che hai preso alla fine. :)
Banalmente, qualsiasi programma che esegue un'azione e mostra una barra di avanzamento (quindi due azioni) utilizzerà più CPU di una che esegue una sola azione.
Tuttavia, questo non significa che debba essere necessariamente più lento nel tempo dell'orologio da parete. In effetti, un 2x rallentamento imho sembra eccessivo.
Alcune strategie includono:
- Non mostra una barra di avanzamento (whis è in realtà l'impostazione predefinita per la maggior parte dei comandi Unix, in cui è necessario aggiungere un'opzione dettagliata)
- Fornire un'opzione silenziosa per disabilitare la barra di avanzamento. Questo dovrebbe effettivamente essere fornito per l'interfaccia utente (ad esempio supponiamo che l'utente lo eseguirà da cron o reindirizzerà l'output a un file), ma avrebbe l'effetto collaterale di aggirare il rallentamento della barra di avanzamento.
- Mostra l'avanzamento attraverso un thread diverso. Probabilmente complesso da eseguire con Python, ma normale con altri linguaggi. Hai un thread della GUI che mostra alcuni progressi e uno di lavoro che esegue il lavoro effettivo.
- Riduzione dell'intervallo di aggiornamento della barra di avanzamento / dimensione del passaggio.
- Se stavi copiando un file byte per byte (per il bene dell'argomento, questo è ovviamente inefficiente), invece di ridisegnare la barra di avanzamento ogni byte, potresti volerlo aggiornare solo dopo ogni MB copiato.
- O dal tempo impiegato, come impostare un timer che aggiorni lo stato ogni X secondi (di nuovo, preferibilmente asincrono rispetto all'azione principale, o su un thread diverso).
- Rendendo la barra di avanzamento il più economica possibile. Questo potrebbe passare dall'emissione di soli punti piuttosto che una barra di avanzamento a tutti gli effetti per avere la barra di avanzamento "disegnata" ed evitare di calcolarla di nuovo ad ogni passaggio (dovresti eseguire l'elaborazione completa su SIGWINCH, però)
In generale, questo è un compromesso previsto
In generale, penso che dipenda se è possibile evitarlo o meno. Se stiamo scaricando un file di grandi dimensioni da Internet, puoi quasi sempre inserire una barra di avanzamento adeguata, poiché il download utilizzerà risorse diverse. Se vuoi copiare file da un filesystem remoto, lento (come uno smartphone), la navigazione in tutto l'albero delle directory che dovrà essere copiato in modo che venga visualizzata una barra di avanzamento7 probabilmente richiederà risorse (la larghezza di banda della connessione con il telefono) che potrebbero essere saltati se i file fossero trovati e copiati "come appaiono".