Oggi con l'hardware e la memoria moderni a buon mercato, che senso ha spendere gli sforzi per analizzare gli algoritmi o la complessità della struttura dei dati?
Non sarebbe meglio invece concentrarsi su codice pulito e gestibile, codice leggibile piuttosto che su ottimizzazioni per la complessità?
Nota: non parlo di sistemi o sistemi embedded con tipi simili di vincoli.
In primo luogo, metto in discussione la premessa della tua domanda. Nessuno esegue deliberatamente "ottimizzazioni per complessità". Le ottimizzazioni vengono eseguite per superare le prestazioni o i limiti di risorse e la complessità è tollerata se riesce a portare a termine il lavoro. Se eseguita correttamente, l'analisi degli algoritmi e delle strutture dati consente di riconoscere le informazioni ridondanti, il lavoro inutile e consente di scrivere codice più semplice e facilmente gestibile, oltre a garantire prestazioni migliori.
In secondo luogo, mentre un hardware più potente potrebbe consentire di risolvere il problema di ieri in modi più ovvi e diretti, molti di noi devono passare a problemi nuovi e più difficili. Il tuo word processor è finalmente abbastanza veloce? Ottimo, ora fallo funzionare interamente in un linguaggio di scripting all'interno di un browser web. Vuoi fare un'indicizzazione approfondita di tutta la rete ogni mese? Belle. Google potrebbe farlo dieci anni fa. Sfortunatamente, se vuoi tenere il passo con Google, devi aumentare il numero di pagine sottoposte a scansione di un ordine di grandezza ogni anno. Ci sono voluti dieci anni per sequenziare la prima copia del genoma umano, ora vogliamo essere in grado di farlo in un giorno.
Per quanto potente sia l'hardware, la difficoltà dei problemi che vogliamo affrontare sta crescendo ancora più velocemente.
Sì, è sempre consigliabile concentrarsi prima sulla correttezza, quindi sulla leggibilità e sulla manutenibilità, quindi - se mai - sulle prestazioni. Nella maggior parte dei casi al giorno d'oggi, le prestazioni non rappresentano un limite significativo.
Detto questo, è ancora una buona pratica scegliere correttamente i tuoi algoritmi e le strutture dati. Se questo significa semplicemente chiamare il giusto tipo di metodo di ordinamento della libreria standard, o usare il giusto tipo di contenitore per un determinato modello di utilizzo, che di solito è facile cambiare in seguito. Ma ogni volta che devi veramente implementare un qualche tipo di algoritmo non banale, vale la pena di pensare in anticipo ai requisiti delle prestazioni. Può darsi che non ci siano molti requisiti prestazionali, come se un algoritmo di ricerca di stringhe venisse chiamato 10 volte al giorno con alcune decine di caratteri di testo. Quindi ovviamente non vale la pena dedicare molto tempo alla ricerca / progettazione delle opzioni dell'algoritmo e alla messa a punto delle sue prestazioni. Tuttavia, se viene chiamato migliaia di volte al giorno con un milione di caratteri ogni volta, la mancanza di prestazioni da parte di un algoritmo male scelto / implementato può effettivamente arrestare il tuo programma.
Quindi è necessario controllare e identificare i potenziali punti caldi delle prestazioni abbastanza presto, e progettarli attentamente se ci sono tali punti caldi. Effettua calcoli back-of-the-envelope per stimare le prestazioni, il throughput, il tempo di risposta ecc. Durante la fase di analisi e progettazione. Questi possono aiutare a scoprire aspettative / assunzioni irrealistiche sul sistema. Costruisci uno scheletro end-to-end del sistema il prima possibile, quindi puoi eseguire alcune misurazioni approssimative (con dati fittizi, flussi di lavoro semplicistici, qualsiasi cosa) per avere un'idea delle prestazioni reali rispetto alle aspettative. È inoltre necessario tenere conto dell'aumento previsto del traffico a breve / lungo termine. Un sito web potrebbe funzionare bene inizialmente con 50 utenti, ma potrebbe causare seri problemi quando la sua base di utenti cresce a migliaia l'anno successivo. È molto doloroso e rischioso provare a risolvere problemi di prestazioni quando il sistema è già completamente congestionato. Molto spesso non è ovvio che il sistema si avvicini al suo punto di congestione: le sue prestazioni possono sembrare sempre accettabili, poi all'improvviso calano drasticamente. Se non puoi prevedere e prevenire questi problemi a tempo debito, dovrai risolverli mentre le chiamate degli utenti arrabbiati stanno allagando le linee di supporto e il tuo capo sta inspirando nel tuo collo aspettando la soluzione immediata ...
Today with the modern hardware and memory coming cheap, how much sense does it make to spend effort to analyze algoriths or data structure complexity?
ha ancora senso oggi.
forse l'esempio migliore che posso dare è quello della crescita dei numeri in cpu (più che in frequenza). scegliere i giusti algoritmi e strutture sono ancora importanti perché hai ancora questi massimi fisici: un programma ben scritto può richiedere una frazione del tempo o delle risorse della CPU.
Un'ovvia alternativa alla scelta degli algoritmi / implementazioni giusti è l'utilizzo dell'esecuzione parallela (PE). anche se in alcuni casi va bene, PE non è sempre una buona soluzione:
dato lo sforzo necessario per implementare correttamente il PE, gli algos e le strutture giuste sono ancora importanti e soluzioni molto più semplici e potenti per molti casi.
quindi, diciamo che hai raggiunto questo limite: preferiresti riadattare il programma per PE, o preferiresti usare (o verificare che il tuo programma stia usando) i tipi / algos / implementazioni corretti?
anche se scegli PE, il tuo programma (nella maggior parte dei casi) finirà col consumare più risorse di picco / totale nella sua esecuzione = =.
Wouldn't it be better instead, to focus on clean, maintainable code, readable code than on optimizations for complexity?
i due possono coesistere. (anche se alcune lingue o i tempi di esecuzione possono influire negativamente su questo, in modo tale che ci sia una minore sovrapposizione - la domanda è indipendente dalla lingua)
Dal punto di vista dell'utente ciò che conta è la reattività . Avere un notebook o un tablet pronto non appena viene acceso è molto importante. Questo non si ottiene solo con enormi frequenze della CPU e piccole latenze di memoria.
Se per complecity intendi anche complessità algoritmica, il punto importante è scalabilità . Le prestazioni dell'hardware sono una soluzione limitata quando il tuo problema è O (exp N).
Non riesco a immaginare un giorno in cui gli allevatori di cavalli da corsa fini e sempre più veloci saranno in grado di compensare i fantini sovrappeso, sempre più grassi.
Gli ingegneri dell'hardware si buttano fuori facendo una litografia più fine e più fine, orologi più veloci, livelli di cache, più CPU su un chip. Nel frattempo, le persone che eseguono il software che quei chip devono eseguire dicono "Performance - a chi importa?"
Le prestazioni contano. La lentezza è come qualsiasi altro tipo di bug.
Dovresti cercare di non farli. Ma li farai (se stai lavorando) e dovresti sapere come rimuoverli.
Guarda le tue esigenze. Codificare in termini specifici, misurabili e oggettivi ciò che costituisce una performance accettabile in modo da avere una visione unitaria tra stakeholder, management e sviluppatore. Lascia che questa sia la tua guida in merito all'architettura applicativa, alla progettazione di applicazioni e hardware, al QA delle prestazioni e delle prestazioni, per sapere se hai colpito il tuo segno e dove spendere il tempo per ottimizzare e quando no.
Se ignori le prestazioni e ritorna a morderti come requisito non inarticolata importante per uno stakeholder chiave, allora sei sr * wed perché è molto più facile da progettare in termini di prestazioni piuttosto che affrontarlo dopo il fatto.
Leggi altre domande sui tag performance algorithms complexity maintainability