Dovrei preoccuparmi delle prestazioni, anche se non ci sono perdite di convenienza? [duplicare]

Question

Dovrei preoccuparmi delle prestazioni, anche se non ci sono perdite di convenienza? [duplicare]

#1 da (3 voti)
#2 da (2 voti)

0

Si supponga che un'applicazione mostri una tabella di dati. I dati vengono caricati da un database quando il programma viene inizializzato.

Ogni valore nella tabella è rappresentato da un campo di input, in cui ogni pressione di un tasto in uno di questi campi provoca un aggiornamento:

I dati vengono scritti nel database
Quindi, ogni valore nella tabella viene aggiornato riassegnando i modelli ai dati

La mia preoccupazione qui è che ogni valore viene aggiornato per ricalcolare un riepilogo, anche quelli che non sono stati toccati affatto.

Tuttavia, l'applicazione funziona velocemente, l'aggiornamento non causa alcun inconveniente all'utente. Devo comunque refactoring la mia domanda?

refactoring architecture performance

posta Sprottenwels 17.09.2014 - 08:36

fonte

2 risposte

Leggi altre domande sui tag refactoring architecture performance

Interfaccia (contratto), Generics (universalità) e metodi di estensione (facilità d'uso). È un design giusto? Progettazione testabile del sito [duplicato]

score 3 · Answer 1

Sono d'accordo che l'accesso al database su ogni macchina da stampa non sia un progetto ottimale. Non ti consiglierei di scriverlo in questo modo se stavi partendo da zero.

Tuttavia, come regola generale, non riscrivere codice funzionante senza una buona ragione. Se l'applicazione funziona bene, non c'è motivo di cambiarla. Assicurati che la tua valutazione dell'applicazione "veloce" sia valida nel tuo caso d'uso reale. Ciò significa testare con abbastanza record e abbastanza connessioni simultanee per replicare ciò che ti aspetti dalla produzione.

score 2 · Answer 2

Citazione di Nielsen. Tempi di risposta: i 3 limiti importanti

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Se stai progettando applicazioni GUI, le prestazioni dovrebbero sempre essere nella tua mente. Se si deve ridimensionare l'applicazione corrente, tuttavia, dipende se l'investimento temporale è valso.