È importante che una soluzione sia efficace?

Risolvo molti problemi, principalmente da Top Coder. Riceverò risposte per molti, ma la maggior parte delle volte finisco con una soluzione inefficiente.

Nelle implementazioni del mondo reale - importa davvero che una soluzione al problema sia efficiente? In tal caso, come posso migliorarlo?

La soluzione migliore è quella che è (in ordine di importanza crescente) efficiente, mantenibile e fatta .

^^^ Questa è l'unica cosa che devi veramente prendere da questa risposta. ^^^

L'efficienza è importante . Forse un po 'meno di quanto non fosse a causa della nostra abbondanza di hardware, ma le prestazioni sono una caratteristica . In un concorso, l'efficienza è ovviamente importante. Dovresti sapere come scrivere codice efficiente. Ancora più importante, dovresti conoscere le migliori pratiche che produrranno un codice efficiente e di buone prestazioni senza sacrificare la tempestività o la manutenibilità di un'applicazione. È proprio qui che la profondità dell'esperienza con una piattaforma e il linguaggio restituisce molti rendimenti.

Ancora più importante (nel 95% dei casi) è avere una soluzione finita e mantenibile. Senza un prodotto finito , non importa quanto sia efficiente o mantenibile la soluzione. Se ti serve uno straordinario tempo per tracciare e correggere un bug o aggiungere una nuova funzionalità, non importa quanto sia efficiente la soluzione. Ma l'efficienza e le prestazioni sono senza dubbio importanti, qualunque cosa si possa dire.

Concordo con Mike Cellini, l'unica cosa che aggiungerei è.

Qualcosa è "abbastanza efficiente"? Ad esempio dal punto di vista dell'utente, non c'è molta differenza tra una funzione che si completa in 0,00001 secondi o una che si completa in 0,1 secondi anche se una è molto più efficiente dell'altra. Una funzione che si completa in 10 minuti non è molto diversa (per l'utente) da quella che si completa in 12 minuti. In entrambi i casi l'utente avrebbe preso una tazza di caffè o avrebbe continuato con un'altra attività.

Ho visto l'efficienza come "un utente efficiente" non un algoritmo efficiente.

In generale, la soluzione più importante a un problema sarà quella che esiste realmente ed è valida per i casi così come esistono per il tuo problema. In altre parole, evita l'ottimizzazione prematura fino a quando non sai effettivamente di avere un codice inefficiente o un codice efficiente che deve essere più veloce.

Inoltre, non dimenticare che la soluzione migliore per la tua applicazione potrebbe non essere la soluzione del caso generale. Caso e punto, un paio d'anni fa un professore ha dato alla nostra classe un problema in cui dovevamo stampare i primi 10 numeri di un determinato tipo (scusate, la mia memoria mi ha deluso sul tipo, ma era uno dei numeri più insoliti classi) e ci è stato dato un test per verificare che il numero fosse il tipo indicato. Questa era la misura del problema che ci era stato dato e ci dissero che era dovuto il giorno successivo con la soluzione più efficiente che riceveva credito. Nella seguente lezione il professore ha riassunto i risultati:

• Alcuni studenti hanno usato un semplice ciclo e la formula fornita per verificare che i numeri fossero corretti e li visualizzavano, lenti ma riuscivano a fare il lavoro, O (n ^ 3).
• Altri studenti hanno fatto le loro ricerche e hanno trovato una formula che faceva un miglior lavoro di controllo per assicurarsi che un determinato numero fosse valido, questi programmi funzionavano molto più velocemente, O (n ^ 2).
• Uno studente ha usato la formula lenta per generare i valori e poi li ha copiati in un array costante nel loro codice e ne ha mostrato il contenuto, O (n).

La soluzione finale è stata giudicata la più efficace dal professore. Si scopre che il problema era in realtà un esercizio per comprendere appieno il problema e non solo uscire e trovare la soluzione più efficiente.

Il punto di cui sopra è che quando si tratta di trovare una soluzione efficiente un problema, è generalmente meglio dedicare del tempo per assicurarsi di capire davvero quale sia il problema prima di andare via e scrivere codice o tentare di ottimizzare il codice. Se riesci a memorizzare un set di valori di riferimento in un array costante, è meglio farlo dal punto di vista delle prestazioni piuttosto che provare a scrivere un algoritmo elaborato.

Allo stesso modo, non dimenticare che per la maggior parte delle applicazioni, le uniche persone che tendono a vedere un codice inefficiente (quando non è inutilmente inefficiente!) Sono gli sviluppatori stessi. Se scrivi codice pulito che fa esattamente esattamente ciò che deve fare, le probabilità sono che la maggior parte delle volte gli utenti non noteranno problemi di prestazioni quando lavorano con il tuo programma e quando ottimizzano solo le parti a cui fanno riferimento voi.

Dipende dalla struttura del concorso, ma generalmente sì: la prestazione è una considerazione la maggior parte delle volte, secondo la loro documentazione . A volte, come nel collegamento successivo, devi cacciare, ma per citare:

Scrivi un codice pulito, chiaro ed efficiente. Anche se non esiste un elemento pubblicitario di recensione specifico per questo, è comunque probabile che i revisori reagiscano meglio al codice che è facile da leggere e comprendere. Con un codice efficiente ottieni un potenziale vantaggio in termini di prestazioni nelle prove di stress e di benchmark, oltre a probabili complimenti (e alcuni punti extra) dai revisori.

Il modo migliore per migliorare è scrivere codice efficiente, che stai già facendo. Anche se completi il ​​lavoro, dedica del tempo a migliorarne l'efficienza, anche dopo la competizione, e questo ti ripagherà.

Probabilmente vuoi anche investire in teoria, come i libri sugli algoritmi , che possono darti due cose: strumenti più efficienti per risolvere un problema specifico e meccanismi più efficienti per identificare quale sia il problema che devi risolvere.

Infine, i corsi di informatica sono sempre più disponibili online e copriranno lo sfondo che devi migliorare.

L'efficienza di una soluzione dipende da una serie di fattori. La cosa più importante è sapere cosa desidera il tuo utente. Ecco alcuni esempi.

1. Se sei l'unico utente di un blocco di codice e funziona bene per te, allora probabilmente stai bene.
2. Se il tuo programma sarà venduto, devi avere in mente una piattaforma di destinazione. Provalo con questa piattaforma. Se il programma è eccezionalmente lento, è necessario lavorare per renderlo più efficiente. Se ti sembra perfetto, consegnalo ad altri utenti e verifica se sono d'accordo.
3. Forse il programma ha altre considerazioni. Se stai costruendo, per esempio, un programma basato su server, potrebbe essere necessario lavorare molto duramente per rendere il programma il più efficiente possibile. Oppure, se funziona su un microprocessore, assicurati che funzioni anche lì.

Come rendere il tuo codice più efficiente:

1. Il primo passo è farsi un'idea di ciò che richiede più tempo. Il trucco è fare qualcosa chiamato codice di profilazione. Cerca ciò che richiede più tempo e vedi se riesci a trovare un modo per farlo funzionare più velocemente.
2. Forse il fattore limitante chiave è la memoria. In tal caso, cerca cosa sta occupando grandi blocchi di memoria e vedi come potresti ridurlo.

C'è un intero campo di ottimizzazione, ma i due suggerimenti sopra dovrebbero almeno iniziare.

Per una competizione devi capire chi sono i giudici e di cosa parlano: se sono alla ricerca di programmatori fantastici e niente di più, otterrai dei complimenti per un codice più efficiente.

Di norma, nel mondo reale, non importa. Una delle idee chiave dello sviluppo del software è "Non ottimizzare ciò che non sai che deve essere ottimizzato", quindi "Ottimizza solo quando è stato dimostrato che è necessario"

Molti professionisti sosterranno che ciò porta a un codice gonfio e inefficiente che non può essere facilmente risolto, e in alcuni casi limite (che canticcheranno come se fosse quello che fanno la maggior parte dei programmatori tutto il giorno ogni giorno) sono corretti. Tuttavia, non molti progetti di sviluppo software hanno i suoi risultati misurati "Prestazioni: più veloci del necessario, Costo: a chi importa, Tempi di consegna: a volte questo decennio", Nel mondo reale, di solito è "Lo voglio a buon mercato, lo voglio ieri, voglio per funzionare ".