Nei giorni del computing moderno, in "tipiche app di business", perché le prestazioni sono importanti? [chiuso]

Hai ragione, il rendimento nelle app aziendali non è un argomento molto importante come viene discusso dalla maggior parte dei programmatori . Di solito, le discussioni relative alle prestazioni che sento dai programmatori hanno diversi problemi:

• Sono principalmente ottimizzazione prematura . Di solito, qualcuno vuole "il modo più veloce" per eseguire un'operazione senza una ragione apparente e finisce per apportare modifiche al codice che sono fatte dalla maggior parte dei compilatori in ogni caso (come la sostituzione della divisione per moltiplicazione o la definizione di un metodo), o trascorrendo giorni facendo cambiamenti che ti aiuterà a guadagnare qualche microsecondo in fase di runtime.

• Sono spesso speculativi . Sono contento di vedere che su Stack Overflow e Programmers.SE, profiling viene citato frequentemente quando la domanda è legata alle prestazioni, ma sono anche deluso quando vedo due programmatori che non conoscono quali profiling stanno discutendo sui cambiamenti relativi alle prestazioni che dovrebbero fare nel loro codice. Credono che i cambiamenti renderanno tutto più veloce, ma praticamente ogni volta, non avranno alcun effetto visibile o rallenteranno le cose, mentre un profiler li avrebbe indirizzati verso un'altra parte del codice che può essere facilmente ottimizzata e che spreca l'80% del tempo.

• Sono focalizzati solo sugli aspetti tecnici. Le prestazioni delle applicazioni orientate all'utente sono il sentimento: si sente veloce e reattivo, o si sente lento e goffo? In questo contesto, i problemi di prestazioni vengono in genere risolti molto meglio dai progettisti dell'esperienza utente: una semplice transizione animata può spesso essere la differenza tra un'app che si sente terribilmente lenta e l'app che si sente reattiva, mentre entrambi spendono 600 Signorina. facendo l'operazione.

• Sono basati su elementi soggettivi anche quando sono correlati a vincoli tecnici. Se non si tratta della sensazione veloce e reattiva, dovrebbe esserci un requisito non funzionale che specifica la velocità con cui un'operazione deve essere eseguita su dati specifici, in esecuzione su un sistema specifico . In realtà, succede più così: il manager dice che trova qualcosa di lento, e quindi gli sviluppatori devono capire cosa significa. È lento come in "dovrebbe essere inferiore a 30 ms mentre al momento, perde dieci secondi", o lento come "possiamo forse ridurre la durata da dieci a nove secondi"?

Early during my career as a programmer, I was working on a piece of software for a bunch of my customers. I was convinced this software is the next great thing which will bring happiness to the world, so I was obviously concerned by performance.

I've heard terms such as "profiling" or "benchmark", but I didn't know what they mean and couldn't care less. Moreover, I was too focused reading the book about C, and especially the chapter where optimization techniques were discussed. When I discovered that computers perform multiplication faster than division, I replaced division by multiplication anywhere I could. When I discovered that calling a method can be slow, I combined as much methods as I could, as if the previous 100 LOC methods weren't already an issue.

Sometimes, I spent nights doing changes which, I was convinced, made difference between a slow app nobody wants, and a fast one everybody wants to download and use. The fact that two actual customers who were interested by this app requested actual features wasn't bothering me: "Who would want a feature, if the app is slow?"—I thought.

Finally, the only two customers stopped using the app. It wasn't amazingly fast despite all my efforts, mostly because when you don't know what indexes are and your app is database-intensive, there is something wrong. Anyway, when I was doing just another performance-related change, which was improving by a few microseconds the execution of code which is used once per month, customers didn't see changes. What they were seeing is that user experience is terrible, documentation is missing, crucial features they were requesting for months were not here and the number of bugs to solve was constantly growing.

Result: I hoped this app will be used by thousands of companies around the world, but today, you won't find any information about this application on the internet. The only two customers abandoned it, and the project was abandoned as well. It was never marketed, never publicly advertised, and today, I'm not even sure I can compile it on my PC (nor find the original sources). This wouldn't have happened if I was focusing more on things that actually matter.

Detto questo, le prestazioni in generale sono importanti :

• Nelle app non aziendali, può diventare cruciale. Esiste software incorporato , il software viene eseguito su server (quando hai qualche migliaio di richieste al secondo, il che non è così grande, le prestazioni iniziano a essere un problema), il software eseguito su smartphone , videogiochi , software per professionisti (prova a gestire un file da 50 GB in Photoshop su una macchina non molto veloce per essere convinto ) e persino prodotti software ordinari venduti a molte persone (se Microsoft Word dedica il doppio del proprio tempo a fare ogni operazione che fa, il tempo perso moltiplicato per il numero di utenti diventerà un problema).

• Nelle app aziendali, ci sono molti casi in cui un'applicazione che sente e è lenta sarà odiata dagli utenti. Non vuoi quello, rendi conto delle tue preoccupazioni.

Sì. Sì, lo fa. La velocità di run-time non è l'unica preoccupazione che dovresti avere, e non è così pressante come nel 1982, o come è ancora nei sistemi embedded a bassa potenza, ma è sempre una preoccupazione, ed è importante che tu capisca perché è così.

Per esempio, la complessità asintotica menzionata descrive il comportamento di un programma man mano che la sua dimensione di input cresce . Un programma non lineare che si occupa di 10 elementi può farla franca con il lavoro superfluo, ma ti morderà quando un giorno dovrai affrontare 1000, perché non sembrerà solo più lento, ma molto, molto più lento. E tu non sai (senza analisi approfondite e benchmarking) se quel punto sarà a 100 articoli, a 1000 articoli, o meno fino a quando non colpirai 100.000 articoli. Può essere difficile da credere, ma scegliere il miglior algoritmo è ovviamente molto più semplice che stimare questo punto per ogni routine e scegliere la tua implementazione a seconda di questa stima.

Inoltre, leggi le nozioni di base sull'esperienza utente. Esistono soglie ben studiate che determinano in che modo viene percepita l'interazione con un programma in base ai suoi tempi di risposta (10 ms, 100 ms, pochi secondi ecc.). L'attraversamento di una di queste soglie causerà il disimpegno degli utenti dalla tua applicazione e, a meno che tu non sia nella felice posizione di scrivere software monopolio che le persone hanno da utilizzare, gli utenti disimpegnati si traducono direttamente in valori aziendali negativi perché conducono alla perdita di clienti.

Questi sono solo alcuni dei motivi per cui un programmatore professionista deve conoscere la complessità algoritmica e gestirla in modo responsabile. In questi giorni di solito non è necessario andare fuori strada e programmare un codice particolarmente ottimizzato e poco leggibile per niente a meno che non si riveli un ciclo interno critico dal punto di vista temporale, ma non si dovrebbe mai, mai invocare una classe di complessità più alta di quanto sia ovviamente necessario per fare il lavoro.

Sì!

Dato che hai chiesto degli esempi, mi vengono in mente varie situazioni quotidiane:

1. Gestione di big-data : molte applicazioni aziendali sono supportate da basi di dati e in molti casi tali database sovraccaricano con i dati. E poiché lo spazio su disco è economico, la quantità di dati registrati e memorizzati è folle. Proprio la settimana scorsa un cliente si è lamentato, che la sua applicazione è talmente lenta, quando mostra solo alcuni numeri medi (query su qualche milione di righe ...) - Anche nell'uso quotidiano abbiamo conversioni e calcoli batch-dati con runtime nella lega di diversi ore. L'anno scorso una ottimizzazione algoritmica ha portato il tempo di processo di un batch esaurito da 8 a 4 ore, ora non collide più con il turno del giorno!

2. Reattività : ci sono stati studi di usabilità (se avessi tempo aggiungerei link alle domande pertinenti su ux.se ...) che la soddisfazione degli utenti è strongmente correlata alla reattività. Una differenza in un tempo di risposta di 200ms contro 400ms può facilmente costarti una grande percentuale dei tuoi clienti che ti lasciano ai tuoi concorrenti.

3. Sistemi incorporati : i computer non stanno diventando più veloci, stanno diventando più lenti e più piccoli ^ _ ^ Lo sviluppo dei dispositivi mobili ha un enorme impatto sullo sviluppo delle applicazioni. Certo, possiamo gettare memoria e cicli di CPU come Jelly Beans sui moderni computer desktop, ma ora il tuo capo ti chiede di implementare l'algoritmo di analisi del sonno su un orologio bizzarro o su una SIM-Card ...

In practice, today does performance matter in a typical normal business program?

Non so cosa sia un normale programma di lavoro normale. Quello che so, è che gli utenti finiscono sempre per alimentare i nostri programmi con molti più dati di quelli che abbiamo pianificato (spesso dopo averli visti quanto grande sarebbe e aggiungendo un margine di sicurezza) e che in tal caso si aspettano un aumento lineare di run-time, accetta un comportamento log n e si lamenta che l'applicazione si blocca quando succede qualcos'altro. E tendono a considerare la dimensione del risultato più della dimensione dell'input, tranne nel caso in cui sia ovvio dal loro POV che tutti i dati di input devono essere elaborati.

Quindi sì, le prestazioni, almeno a livello di complessità, contano. La micro-ottimizzazione all'interno di una classe di complessità non ha molta importanza, a meno che tu non sia visibilmente peggiore della concorrenza (sia nei benchmark in alcuni mercati o per la percezione grezza) - cambiando la classe nella progressione "istantanea", "non istantanea ma l'utente non passare a qualcos'altro "," abbastanza lento da consentire all'utente di passare a qualcos'altro con il rischio di interruzione del flusso di azioni "," abbastanza lento da consentire all'utente di avviare l'attività e quindi controllare di volta in volta "," abbastanza lento che l'utente pianifica di avviare l'attività a pranzo, durante la notte, durante il fine settimana ").

Nelle moderne applicazioni aziendali, i problemi di prestazioni non sono in termini di mancanza di CPU o memoria. Ma sono in forma di latenze di rete, prestazioni di I / O e astrazioni che nascondono tutti questi elementi. Tutto dipende da quanto è buono il design e quanto sono esperti gli sviluppatori. Persino la semplice applicazione CRUD può fermarsi lentamente se preleva da DB una riga alla volta invece di eseguire una query (nota anche come problema N + 1).

Il problema è che avere un buon design e sviluppatori esperti è costoso. Ed è di solito molto più economico avere utenti irritati che investire in reali ottimizzazioni delle prestazioni. Vi sono alcuni casi in cui i clienti richiedono prestazioni elevate (ad esempio i browser Web), ma raramente si applicano alle applicazioni aziendali più comuni.

Tieni presente che per le applicazioni basate su server, potresti avere centinaia, migliaia o addirittura milioni di utenti che cercano di fare le cose nello stesso momento. Un piccolo risparmio in termini di efficienza in una situazione del genere può avere un impatto significativo sulla quantità di hardware necessaria per soddisfare le richieste di assistenza.

Sicuramente è molto importante.

Il problema principale non è nemmeno l'essere fastidiosi per l'utente, come sperimentare ritardi inutili quando gli elementi della GUI vengono sovrascritti due volte o tre volte (che fa importa sulla grafica integrata!) o semplicemente perché il programma ci vuole così tanto tempo per fare ... qualunque cosa faccia (cose per lo più poco interessanti). Anche se, naturalmente, questo è anche un problema.

Ci sono tre idee sbagliate importanti:

1. I computer aziendali più tipici non sono "molto più potenti" . Il tipico computer aziendale è non un i7 a 8 core con una scheda grafica kick-ass e 16 GB di RAM. È un notebook con processore mobile di classe media, grafica integrata, 2 GB di memoria principale (4 GB se si è fortunati), un disco da 5400 RPM e una versione aziendale di Windows con una varietà di antivirus in tempo reale e software di applicazione delle policy in esecuzione nel sfondo. Oppure, per la maggior parte dei consulenti, il "computer" è semplicemente l'iPhone ...
2. La maggior parte degli "utenti aziendali tipici" non sono tecnici, non capiscono le implicazioni della creazione di un foglio di calcolo con 10-12 schede di riferimento incrociato, 150 colonne e 30.000 righe (queste cifre non sono irrealistiche come si può presumere! ) e loro non vogliono sapere neanche. Lo faranno.
3. Una seconda perdita non costa è un'ipotesi sfacciatamente sbagliata.

Mia moglie lavora all'estremità superiore di un "tipico ambiente di lavoro". Il computer che sta utilizzando costa circa 3,5 ore del suo orario di lavoro vale la pena. L'avvio di Microsoft Outlook richiede una buona giornata, circa 3 minuti fino a quando non è pronto (6-8 minuti sul quarto di coda quando i server sono sottoposti a un carico pesante). Alcuni di quei fogli di calcolo a 30k menzionati richiedono 2-3 secondi per aggiornare un valore durante il quale il computer è "congelato" (per non parlare di quanto tempo occorra ad Excel per avviarlo e aprirlo in primo luogo!). È ancora peggio quando si condivide il desktop. Non farmi nemmeno andare su SAP.
Sicuramente importa se centomila persone perdono ogni 20-25 minuti per giorno lavorativo senza aspettare nulla. Quelli sono milioni persi che potresti, invece di perderli, pagare come dividendi (o pagare salari più alti).
Certo, la maggior parte degli impiegati si trova all'estremità inferiore della piattaforma, ma anche nella fascia più bassa il tempo è denaro .

I can understand why it used to matter, decades ago. Computers were much slower and had much less memory, so you had to think carefully about these things.

Sembri sottovalutare quanto velocemente cresce N ^ 2. Diciamo che abbiamo un computer e il nostro algoritmo N ^ 2 impiega 10 secondi quando N = 10. Il tempo passa ora abbiamo un nuovo processore che è 6 volte più veloce del nostro originale, quindi il nostro calcolo da 10 secondi è ora a meno di due secondi. Quanto può essere più grande N e si adatta ancora a quell'originale tempo di esecuzione di 10 secondi? Ora possiamo gestire 24 articoli, un po 'più del doppio. Quanto più veloce sarebbe il nostro sistema per gestire 10 volte più articoli? Beh, dovrebbe essere 100 volte più veloce. I dati crescono molto velocemente e cancellano il progresso dell'hardware dei computer per gli algoritmi N ^ 2.

Non crederesti alla quantità di programmi aziendali di terze parti che usiamo al lavoro, e molti di loro sono semplicemente ridicolmente lenti da usare rispetto ai miei standard personali. Se i programmi fossero qualcosa che uso a casa, li avrei sostituiti con uno alternativo molto tempo fa.

In alcuni casi, la differenza va direttamente ai costi, in quanto alcuni programmi influenzano direttamente il numero di attività che posso eseguire durante un giorno, riducendo così la mia produttività e la quantità di articoli fatturabili. Quindi direi che è molto importante anche per i programmi di business essere almeno abbastanza performante da non essere l'elemento limitante per il reddito.

Un esempio è la gestione degli incidenti in cui il lavoro viene misurato a intervalli di 15 minuti (service desk). Se il programma è abbastanza lento da spingere un ticket per impiegare più di 15 minuti (incluso il lavoro effettivo), rallenterà molto il processo. Una causa potrebbe essere un accesso lento al database che semplicemente "aspetta un po '" ogni volta che l'utente fa un'azione (compila i dettagli della risoluzione, aggiorna le informazioni di lavoro o simili). Posso immaginare che ci siano casi in cui i programmi lenti possono persino influire su aspetti più critici, come i dettagli dei pazienti ospedalieri sui casi di avvelenamento urgente - forse allergie alle medicine o cose del genere?

Molte delle altre risposte trattano l'argomento in modo abbastanza approfondito, quindi mi rivolgo a loro per le ragioni e le motivazioni. Invece, voglio dare un esempio di vita reale per mostrare come una scelta algoritmica può avere implicazioni reali.

link

L'articolo collegato descrive un bug nell'algoritmo per calcolare gli aggiornamenti di Windows XP. Per gran parte della vita di Windows XP, l'algoritmo di aggiornamento ha funzionato correttamente. L'algoritmo calcola se una patch è stata sostituita da una patch più recente e non è quindi necessario installarla. Verso la fine, però, l'elenco degli aggiornamenti sostituiti è cresciuto molto a lungo *.

L'algoritmo di aggiornamento era esponenziale, in cui ogni nuovo aggiornamento impiegava il doppio del tempo per calcolare quello precedente ( O(n) = 2n ). Quando gli elenchi sono entrati nell'intervallo di 40 aggiornamenti (* lungo ), sono necessari fino a 15 minuti, a piena capacità, per verificare la disponibilità di aggiornamenti. Questo ha effettivamente bloccato molte macchine XP durante l'aggiornamento. Peggio ancora, quando si andava ad installare gli aggiornamenti, l'algoritmo eseguiva di nuovo , impiegando altri 15 minuti. Poiché molte macchine disponevano di Aggiornamenti automatici, questo poteva bloccare le macchine per 15 minuti ad ogni avvio, e potenzialmente di nuovo ad una certa periodicità.

Microsoft ha utilizzato sia hack a breve termine (rimozione degli elementi dall'elenco degli aggiornamenti) sia correzioni a lungo termine per risolvere questo problema. Questo era importante perché anche le ultime versioni di Windows utilizzavano lo stesso algoritmo e potrebbero un giorno affrontare lo stesso problema.

Qui possiamo vedere che la scelta di un algoritmo ha implicazioni reali. L'algoritmo sbagliato, sebbene valido per la maggior parte della vita del prodotto, può ancora avere impatti negativi lungo la strada.

Penso che tu stia interpretando la quantità di domande relative al rendimento come un'indicazione che i requisiti di rendimento per le app aziendali sono importanti invece di riconoscere che migliorare le prestazioni è difficile . Il solo fatto di farlo funzionare può essere realizzato con tecniche a forza bruta, prove ed errori o copiando e incollando il codice di esempio.

Chiunque può avere fortuna e continuare a fare cambiamenti finché qualcosa non corre più veloce, ma raramente funziona. A causa della mancanza di esperienza, gli sviluppatori vedranno un aiuto esterno. In alcuni ambienti, i miglioramenti delle prestazioni sono un problema univoco, quindi è possibile che una domanda specifica su un sito come StackOverflow sia l'unica opzione. Inoltre, molti consulenti fanno i loro soldi essendo in grado di intervenire e risolvere questo tipo di problemi.

Dipende pesantemente da come definite "buona prestazione". I tuoi algoritmi dovrebbero sempre usare la migliore complessità possibile. Abusi scappatoie per accelerare la tua gabbia media. Buffer e precarico / precompilare ove possibile in un programma interattivo.

Esiste un'altra definizione di "buona prestazione": ottimizzazione delle costanti della classe di complessità. È qui che C ++ ottiene il suo titolo, dove le persone iniziano a chiamare Java lentamente, dove il 5% in meno di runtime sembra essere il Santo Graal. Usando questa definizione hai ragione. L'hardware del computer diventa più complicato con il tempo, mentre i compilatori migliorano sempre di più. Ad un certo punto non puoi davvero ottimizzare il codice di fascia bassa meglio del compilatore, quindi lascia che sia e concentrati sui tuoi algoritmi.

A quel punto usare Java / Haskell / C ++ diventa solo un'altra decisione progettuale. Il numero di crunch può essere fatto tramite OpenCL sulla tua GPU. Le interfacce utente richiedono algoritmi a tempo costante e sono buone. L'output e la modularità sono più importanti dell'allineamento delle classi per un utilizzo della cache del 20% migliore. Il multithreading diventa importante, perché le persone non vogliono un'app veloce, ne vogliono una reattiva. Ciò che non è importante è che la tua app sia costantemente il 10% più lenta di quanto potrebbe essere. Anche il 50% va bene (ma la gente inizia a fare domande allora). Concentrati su correttezza, reattività e modularità.

Adoro programmare in Haskell o almeno in una forma funzionale (anche in C ++). Essere in grado di scrivere test facilmente per l'intero programma è semplicemente più importante di essere un po 'più veloce nei lavori batch.

Semplice: costo

Il mio precedente datore di lavoro aveva un sistema di gestione dell'apprendimento che era ospitato su server fisici come un modello SaaS. L'heap della JVM era configurato per 2 GB per le macchine precedenti e 3 GB per le macchine più recenti e abbiamo eseguito diverse istanze per macchina. Penseresti che sarebbe abbastanza.

Prima di iniziare, c'era un team di prestazioni responsabile di rendere il sistema reattivo e scalabile. Hanno scoperto che c'erano determinati pezzi di dati che abbiamo interrogato costantemente dal database. C'era una tabella in cui ci siamo addirittura uniti alla maggior parte delle query per recuperare una colonna. Questi dati sono cambiati raramente.

Il problema è che avevamo 2 GB con cui lavorare. Quindi la soluzione ovvia è iniziare a memorizzare nella cache tutti i dati letti di frequente. Poi abbiamo avuto problemi di memoria, iniziando subito prima di salire a bordo.

C'erano due scuole di pensiero su questo:

1. La memoria e l'hardware in generale sono economici in questi giorni. Basta acquistare più RAM in modo da poter memorizzare più cache.
2. Perché un sistema di gestione dell'apprendimento richiede più di 3 GB di RAM? Tutto ciò emette query SQL, invia reindirizzamenti per avviare corsi e valuta i progressi degli studenti attraverso i corsi.

Il secondo argomento ha vinto e ho passato più di un anno a perfezionare l'utilizzo della memoria.

Il mio attuale datore di lavoro ospita anche un sistema di gestione dell'apprendimento, ma lo ospita in modo un po 'diverso. La scalabilità è così scarsa che una singola installazione (suddivisa su 4 server virtuali con carico bilanciato) può gestire solo 80 clienti. Alcuni dei nostri clienti più grandi hanno persino il proprio set di server. La maggior parte dei problemi che portano a questo sono problemi di prestazioni, come le query SQL che gestiscono tutti i cicli della CPU, perdite di memoria, codice ridondante che fa la stessa cosa più volte. Abbiamo persino un'app in-house costruita il cui unico scopo è riavviare i server quando non si comportano male. C'è un dipendente che mantiene lo strumento (insieme ad altre responsabilità).

Si sono iscritti alla prima scuola di pensiero che ho menzionato sopra: gettare più hardware perché i costi dell'hardware sono più economici dei salari degli sviluppatori.

Questo non ha funzionato in modo economico come previsto. Tra hardware, licenze software e personale di supporto per gestire i server, abbiamo speso milioni ogni anno per evitare che il codice di profilazione del tempo di sviluppo degli sviluppatori fosse ridotto.

Quando sono entrato, sono stato reso responsabile della risoluzione dei nostri problemi di disponibilità. Poiché la maggior parte dei nostri problemi di disponibilità erano dovuti a scarse prestazioni, ho ottimizzato le prestazioni del nostro codice e la scalabilità è stata sostanzialmente migliorata, con tempi di attività migliori. Siamo pronti per iniziare ad aumentare la densità. Inutile dire che il mio stipendio non è neanche lontanamente un milione (mi auguro!), Quindi spendere soldi per farmi ottimizzare il codice finirà per farci risparmiare milioni all'anno.

TL; DR

Se esegui un'approfondita analisi costi / benefici, vedrai che è più economico correggere il codice. Un noto problema di prestazioni che ignori si trasforma in debito tecnico .

Ho compreso la tua domanda in questo modo: per ottenere prestazioni sufficientemente buone (ad esempio, gli utenti sono felici e il mio backend non si arrende), devo capire la teoria sulla complessità algoritmica?

Dipende da cosa intendi per applicazione aziendale "tipica". In molti casi, in particolare i semplici sistemi di informazione di tipo CRUD, la risposta sarebbe no. Per questi "semplicemente" (a volte è davvero difficile) è necessario essere in grado di tracciare i colli di bottiglia delle prestazioni: ho perso un indice nel mio database? Posso inviare troppi dati sulla rete? Ho un migliaio di dollari nel mio front-end angular.js? Si tratta di costruire un'architettura sonora, conoscendo bene lo stack tecnologico ed evitando il non senso. Puoi ottenerlo se sei un bravo artigiano, non necessariamente uno scienziato informatico. Un altro modo per dirlo è che i ragazzi che hanno creato l'ottimizzatore di query Oracle hanno affrontato la complessità algoritmica, hai solo bisogno di usare correttamente ciò che ti hanno fornito.

Ora ci sono delle eccezioni. Se stiamo parlando di big data o machine learning, devi sapere cosa stai facendo e non usare solo gli algoritmi predefiniti a tua disposizione. Anche nel front-end, se inizi a sviluppare visualizzazioni di dati avanzate, alcune di esse possono implicare un costo di complessità non lineare (ad esempio grafici di layout di forza).

Al giorno d'oggi queste eccezioni stanno diventando sempre più comuni e il mercato è piuttosto secco quando cerchi persone in grado di gestirli. Quindi: sì, puoi avere successo senza conoscenze informatiche, ma lo sarai ancora di più con alcuni.

Gli altri risponditori hanno coperto la maggior parte dei punti di base, ma per le attività che possono essere parallelizzate, un software inefficiente porta a maggiori costi hardware sotto forma di più server, che consumano più energia e richiedono più spazio e manutenzione.