Quando è il momento giusto per ragionare sulle prestazioni in Haskell?

Le altre risposte forniscono un ampio consiglio sul ragionamento delle prestazioni. Questa risposta riguarda specificamente la semantica non severa.

Mentre la pigrizia rende più difficile ragionare sulle prestazioni, non è così complicato come si potrebbe pensare. Sebbene la pigrizia sia abbastanza utile in alcune situazioni, la maggior parte delle volte una lingua pigra viene utilizzata nello stesso modo in cui verrebbe utilizzato un linguaggio rigoroso. Di conseguenza, il ragionamento delle prestazioni per linguaggi rigorosi può essere applicato (con poche modifiche) alle lingue pigre.

In termini di complessità temporale, una valutazione entusiasta fa molto più lavoro che una valutazione pigra. Entrambe le strategie producono lo stesso risultato nella maggior parte dei casi. (Più precisamente, se la valutazione appassionata non incappa in alcun errore, produce lo stesso risultato della valutazione lenta). Pertanto, per ragionare sulla complessità temporale di un programma Haskell, puoi fingere di valutare con entusiasmo. In quelle rare situazioni in cui la pigrizia conta, questa stima sarà troppo alta e dovrebbe essere rivista al ribasso.

Sebbene la valutazione lazy offra una complessità di tempo inferiore rispetto a una valutazione entusiasta, a volte ti dà una maggiore complessità spaziale, cioè perdite di spazio. Una maggiore complessità spaziale può essere risolta aggiungendo annotazioni di rigore per rendere più arduo l'esecuzione di un programma. Gli strumenti di profilazione sono abbastanza bravi a rintracciare la causa delle perdite di spazio. Lo classificherei come debug di correttezza o debug delle prestazioni, a seconda della gravità.

Ottimizza le grandi cose prima del codice e le piccole cose quando hai finito.

Ad esempio, prima di iniziare la codifica dovresti pensare a quanto segue:

• Le librerie / i framework che stai per utilizzare sono abbastanza veloci?
• Cerca di mantenere le tue strutture dati semplici.
• Cerca di mantenere i tuoi algoritmi e modelli di progettazione il più semplice possibile.
• Quanto è veloce la lingua che sto utilizzando?

... e così via.

Poi, quando hai quasi finito con il tuo codice, pensa alle piccole cose come la funzione incorporata è più veloce, dovrei riscrivere quell'area di codice per renderla più efficiente, ecc.

Questo è vero per qualsiasi lingua, e in realtà dipende dal tipo di software che stai scrivendo. Haskell è un linguaggio generico, quindi probabilmente sei (correggimi se sbaglio) non facendo qualcosa che deve essere estremamente veloce. In tal caso, dovresti utilizzare una lingua di livello inferiore. Se la velocità è un problema, ma non abbastanza da utilizzare un linguaggio di basso livello, dovresti ottimizzare le tue prestazioni in base a quanto sopra.

Naturalmente, ognuno fa le cose in modo diverso, quindi se la tua esperienza personale ti fa pensare che dovresti farlo in modo diverso in base alla tua situazione, allora probabilmente dovresti.

Vorrei aggiungere alla risposta di Dynamic:

• Rendi il tuo codice modulare e liberamente accoppiato .
• Nascondi i dettagli di implementazione dei tuoi moduli.

Quando ti rendi conto in seguito di quali colli di bottiglia ha il collo di bottiglia, può essere davvero doloroso rifattorizzare l'intero progetto. Se il tuo codice è ben strutturato, i colli di bottiglia sono più facili da trovare e da ottimizzare / correggere.