Indirection: Readability vs Performance [closed]

Question

Indirection: Readability vs Performance [closed]

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

0

(Vedo che ci sono molte domande simili, ma le risposte non sono proprio ciò a cui sono interessato.)

La cosa che mi turba è l'indecisione. Se scrivo qualcosa, tendo ad allineare il maggior numero possibile di cose. Potrei essere meno severo in questo linguaggio compilato sperando che il compilatore faccia tutto il possibile per me. Aggiungere ancora strati di riferimento indiretto mi sembra "aggiungerò un po 'più di carico all'utente in runtime, così potrei avere un codice più bello qui" - qualcosa che potrebbe essere risolto con un commento o un disegno diverso (che in realtà vorrei preferisco ma ci vorrà ancora un po 'di tempo). Vedendo una piccola funzione che viene utilizzata solo una volta devo effettivamente combattere la voglia di inline. Avere una moltitudine di classi monouso mi fa venir voglia di creare una soluzione diversa (e di solito totalmente orientata alla procedura).

Quanto è grave? Quanti livelli di riferimento indiretto sono effettivamente OK per avere?

performance pragmatism

posta aragaer 19.02.2014 - 21:39

fonte

3 risposte

Leggi altre domande sui tag performance pragmatism

In che modo il sistema operativo riprende il controllo durante il multitasking? [duplicare] Quanti sviluppatori sulla stessa macchina Microsoft Windows virtualizzata?

score 9 · Answer 1

Non c'è dubbio che l'indirezione (del tipo che descrivi) è vantaggiosa per i programmatori. Ciò che potresti non considerare è questo:

Il tempo del programmatore è molto costoso, ma
Le chiamate al metodo non lo sono.

Il codice più bello non è solo un presunzione; ha profonde preoccupazioni pratiche. Ogni minuto trascorso a comprendere un codice che non è stato ridefinito in un metodo (accompagnato da una propria piccola raccolta di test unitari per dimostrare che funziona ancora) è un minuto in meno che è possibile spendere per apportare miglioramenti al software o aggiungendo nuove funzionalità.

score 3 · Answer 2

C'è una buona ragione per cui Knuth ha detto che l'ottimizzazione prematura è la radice di tutto il male:

Se il tuo programma non è corretto, non importa quanto velocemente funzioni.
La maggior parte delle prestazioni derivano dall'ottimizzazione di una piccola quantità di codice (la regola 80-20).
Il compilatore è probabilmente migliore di inlining e altre ottimizzazioni meccaniche di te.

Scrivi prima per correttezza e chiarezza. Misurare. Decidi se hai effettivamente un problema di prestazioni. Se lo fai, trova il collo di bottiglia. Quindi potresti ottimizzare.

score 0 · Answer 3

Seeing a small function that is used only once I have to actually fight the urge to inline it.

Questo è male. Di solito non è corretto per la leggibilità e talvolta anche cattivo per le prestazioni .

Quanto segue è piuttosto specifico di Java, ma potrebbe essere applicato ad altri compilatori che lavorano con le statistiche.

Se non si incorpora un metodo, il compilatore può scegliere di farlo o meno. Se il metodo viene chiamato di rado, non verrà visualizzato e non ingrandirà il codice. Questo lascia più spazio per l'inlining di metodi più importanti e anche lo srotolamento del ciclo.

Se lo si inline, non può essere "out-lined" e può ostacolare le ottimizzazioni. Questa non è una teoria, vedi per es. il commento alla riga 269 di questa libreria classe .