Ai tempi dell'informatica moderna, nelle "tipiche app aziendali": perché le prestazioni contano? [chiuso]

Questa potrebbe sembrare una domanda strana per alcuni di voi.

Sono un programmatore di hobby per Java. Ho sviluppato diversi giochi, un programma AI che crea musica, un altro programma per la pittura e cose simili. Questo per dirti che ho un'esperienza nella programmazione, ma non nello sviluppo professionale di applicazioni aziendali.

Vedo molti discorsi su questo sito sulle prestazioni. Le persone spesso discutono su quale sarebbe l'algoritmo più efficiente in C # per eseguire un'attività, o perché Python è lento e Java è più veloce, ecc.

Quello che sto cercando di capire è: perché è importante?

Ci sono aree specifiche dell'informatica in cui vedo perché le prestazioni contano: giochi, in cui decine di migliaia di calcoli avvengono ogni secondo in un ciclo di aggiornamento costante o sistemi a basso livello su cui fanno affidamento altri programmi, come sistemi operativi e macchine virtuali, ecc.

Ma per la normale e tipica app aziendale di alto livello, perché le prestazioni sono importanti?

Riesco a capire il motivo per cui importava, decenni fa. I computer erano molto più lenti e avevano molta meno memoria, quindi hai dovuto riflettere attentamente su queste cose.

Ma oggi abbiamo così tanta memoria da risparmiare e i computer sono così veloci: importa davvero se un particolare algoritmo Java è O (n ^ 2)? Farà davvero la differenza per gli utenti finali di questa tipica app aziendale?

Quando si preme un pulsante della GUI in una tipica app aziendale e dietro le quinte si richiama un algoritmo O (n ^ 2), in questi giorni dell'informatica moderna , si sente effettivamente l'inefficienza?

La mia domanda è divisa in due:

1. In pratica, oggi le prestazioni contano in un normale programma aziendale normale?
2. In tal caso, ti prego di darmi esempi reali di luoghi in tale applicazione, in cui le prestazioni e le ottimizzazioni sono importanti.

Hai ragione, le prestazioni nelle app aziendali non sono in realtà un argomento importante nel modo in cui vengono discusse dalla maggior parte dei programmatori . Di solito, le discussioni relative alle prestazioni che sento dai programmatori hanno diversi problemi:

• Sono per lo più 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 vengono comunque eseguite dalla maggior parte dei compilatori (come sostituire la divisione con la moltiplicazione o incorporare un metodo) o passare giorni a apportare modifiche che ti aiuterà a guadagnare qualche microsecondo in fase di esecuzione.

• Sono spesso speculativi . Sono contento di vedere che su Stack Overflow e Programmers.SE, la profilazione viene menzionata frequentemente quando la domanda è correlata alle prestazioni, ma sono anche delusa quando vedo due programmatori che non sanno di cosa stanno discutendo la profilazione sulle prestazioni- modifiche correlate 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 su aspetti tecnici. Le prestazioni delle applicazioni orientate all'utente riguardano la sensazione: si sente veloce e reattivo o si sente lento e goffo? In questo contesto, i problemi di prestazioni sono generalmente 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 impiegano 600 ms. fare l'operazione.

• Si basano su elementi soggettivi anche quando sono collegati a vincoli tecnici. Se non si tratta di sentirsi veloci e reattivi, 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 "dovrebbe essere inferiore a 30 ms. Mentre attualmente spreca dieci secondi" o lento come "possiamo forse ridurre la durata da dieci a nove secondi"?

All'inizio della mia carriera di programmatore, stavo lavorando a un software per un gruppo di miei clienti. Ero convinto che questo software fosse la prossima grande cosa che porterà felicità al mondo, quindi ero ovviamente preoccupato per le prestazioni.

Ho sentito termini come "profiling" o "benchmark", ma non sapevo cosa significassero e non me ne può fregare di meno. Inoltre, ero troppo concentrato a leggere il libro su C, e in particolare il capitolo in cui venivano discusse le tecniche di ottimizzazione. Quando ho scoperto che i computer eseguono la moltiplicazione più velocemente della divisione, ho sostituito la divisione con la moltiplicazione ovunque possibile. Quando ho scoperto che chiamare un metodo può essere lento, ho combinato quanti più metodi possibili, come se i precedenti 100 metodi LOC non fossero già un problema.

A volte ho passato notti a fare cambiamenti che, ne ero convinto, hanno fatto la differenza tra un'app lenta che nessuno vuole e una veloce che tutti vogliono scaricare e usare. Il fatto che due clienti reali interessati a questa app richiedessero funzionalità reali non mi dava fastidio: "Chi vorrebbe una funzionalità, se l'app è lenta?" - Ho pensato.

Infine, gli unici due clienti hanno smesso di usare l'app. Non è stato incredibilmente veloce nonostante tutti i miei sforzi, soprattutto perché quando non sai cosa sono gli indici e la tua app è ad uso intensivo di database, c'è qualcosa che non va. Ad ogni modo, quando stavo facendo solo un'altra modifica relativa alle prestazioni, che stava migliorando di alcuni microsecondi l'esecuzione del codice che viene utilizzato una volta al mese, i clienti non vedevano cambiamenti. Quello che stavano vedendo è che l'esperienza dell'utente è terribile, manca la documentazione, le funzionalità cruciali che richiedevano da mesi non erano qui e il numero di bug da risolvere era in costante aumento.

Risultato: spero che questa app venga utilizzata da migliaia di aziende in tutto il mondo, ma oggi non troverai informazioni su questa applicazione su Internet. Gli unici due clienti lo abbandonarono e anche il progetto fu abbandonato. Non è mai stato commercializzato, mai pubblicizzato pubblicamente e oggi non sono nemmeno sicuro di poterlo compilare sul mio PC (né trovare le fonti originali). Ciò non sarebbe accaduto se mi stessi concentrando di più su cose che contano davvero.

Detto questo, le prestazioni in generale sono importanti :

• Nelle app non aziendali, può diventare cruciale. Esistono software integrati , software eseguito su server (quando hai qualche migliaio di richieste al secondo, il che non è così grande, le prestazioni iniziano a destare preoccupazione), 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 che vengono venduti a molte persone (se Microsoft Word impiega il doppio del tempo per fare ogni operazione che fa, il tempo perso moltiplicato per il numero degli utenti diventerà un problema).

• Nelle app aziendali, ci sono molti casi in cui un'applicazione che si sente ed è lenta sarà odiata dagli utenti. Non lo vuoi, facendo performance delle tue preoccupazioni.

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

Per uno, la complessità asintotica che citi descrive il comportamento di un programma man mano che la sua dimensione di input aumenta . Un programma non lineare che si occupa di 10 elementi può cavarsela facendo un lavoro superfluo, ma ti morderà quando un giorno dovrai occuparti di 1000, perché non sembrerà solo più lento, ma molto, molto più lento. E non sai (senza analisi approfondite e benchmarking) se quel punto sarà a 100 oggetti, a 1000 oggetti o meno fino a quando non colpisci 100.000 oggetti. Può essere difficile da credere, ma scegliere l'algoritmo migliore è ovviamente molto più semplice che stimare questo punto per ogni routine e scegliere l'implementazione in base a questa stima.

Inoltre, leggi le nozioni di base sull'esperienza utente. Esistono soglie ben studiate che determinano il modo in cui viene percepita l'interazione con un programma in base ai suoi tempi di risposta (10 ms, 100 ms, pochi secondi ecc.). Attraversare una di queste soglie provocherà il disimpegno degli utenti dall'applicazione e, a meno che non si sia nella felice posizione di scrivere software di monopolio che le persone devono utilizzare, gli utenti disimpegnati si traducono direttamente in un valore commerciale negativo perché porta 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 fare di tutto per programmare codice particolarmente ottimizzato e male leggibile per qualsiasi cosa a meno che non si sia rivelato un ciclo interno critico nel tempo, ma non dovresti mai, mai invocare una classe di complessità superiore a quella ovviamente necessaria fare il lavoro.

Sì lo fa!

Da quando hai chiesto esempi, mi vengono in mente diverse situazioni quotidiane:

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

2. Reattività : ci sono stati studi di usabilità (se avrò tempo aggiungerò collegamenti alle domande pertinenti su ux.se ...) che la soddisfazione degli utenti è fortemente correlata alla reattività. Una differenza in un tempo di risposta di 200ms contro 400ms può facilmente costare una grande percentuale dei tuoi clienti lasciandoti per i tuoi concorrenti.

3. Sistemi integrati : i computer non stanno diventando più veloci, stanno diventando più lenti e più piccoli ^ _ ^ Lo sviluppo mobile ha un impatto enorme sullo sviluppo delle applicazioni. Certo che possiamo gettare in giro cicli di memoria e CPU come Jelly Beans su moderni computer desktop, ma ora il tuo capo ti chiede di implementare l'algoritmo di analisi del sonno su un orologio strano o su una scheda SIM ...

In pratica, oggi le prestazioni contano in un normale programma aziendale normale?

Non so cosa sia un normale programma aziendale normale. Quello che so è che gli utenti finiscono sempre per alimentare i nostri programmi con molti più dati di quelli che avevamo pianificato (spesso dopo aver chiesto loro quanto sarebbe grande e aggiungendo un margine di sicurezza) e che in questi casi si aspettano un aumento lineare di runtime, 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 escluso nel caso in cui sia ovvio dal loro POV che tutti i dati di input debbano 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, tranne se si è visibilmente peggiori della concorrenza (o nei benchmark in alcuni mercati o per percezione grezza - cambiando la classe nella progressione "istantanea", "non istantanea ma l'utente non lo fa passa a qualcos'altro "," abbastanza lento che l'utente passa a qualcos'altro a rischio di interrompere il flusso di azioni "," abbastanza lento che l'utente avvia l'attività e quindi controlla di volta in volta "," abbastanza lento che l'utente ha intenzione di lanciare l'attività a pranzo, a notte, a fine settimana ").

Nelle moderne applicazioni aziendali, i problemi di prestazioni non sono in forma di mancanza di CPU o memoria. Ma sono in forma di latenze di rete, prestazioni I / O e astrazioni che nascondono tutto ciò. Tutto dipende da quanto è buono il design e dall'esperienza degli sviluppatori. Anche una semplice applicazione CRUD può fermarsi se sta estraendo dal DB una riga alla volta invece di eseguire una query (noto anche come problema N + 1).

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

Tieni presente che per le applicazioni basate su server, potresti avere centinaia, migliaia o addirittura milioni di utenti che provano a fare le cose contemporaneamente. Un piccolo risparmio in termini di efficienza in una situazione del genere può avere un impatto notevole sulla quantità di hardware richiesta per soddisfare le richieste.

Certamente conta molto.

Il problema principale non è nemmeno di essere fastidioso per l'utente, ad esempio sperimentando ritardi inutili quando elementi della GUI sono scoperti due o tre volte (che fa materia sulla grafica integrata!) O semplicemente perché il programma vuole tanto tempo per fare ... qualsiasi cosa fa (roba per lo più poco interessante). Anche se ovviamente, anche questo è un problema.

Vi sono tre importanti idee sbagliate:

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 un processore mobile di fascia media, grafica integrata, 2 GB di memoria principale (4 GB se sei fortunato), 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. O, per la maggior parte dei consulenti, il "computer" è semplicemente l'iPhone ...
2. La maggior parte degli "utenti aziendali tipici" non sono tecnici, non comprendono 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 così irrealistiche come si potrebbe supporre!) non voglio sapere neanche. Lo faranno e basta.
3. Una seconda perdita non costa è un presupposto palesemente sbagliato.

Mia moglie lavora all'estremità superiore di un "tipico ambiente aziendale". Il computer che sta usando costa circa 3,5 ore del suo orario di lavoro. L'avvio di Microsoft Outlook richiede, in una buona giornata, circa 3 minuti prima che sia pronto (6-8 minuti a fine trimestre quando i server sono sotto carico). Alcuni di quei fogli di calcolo di 30k righe menzionati impiegano 2-3 secondi per l'aggiornamento di un valore durante il quale il computer viene "congelato" (per non parlare di quanto tempo impiega Excel per avviarsi e aprirli in primo luogo!). È ancora peggio quando si condivide il desktop. Non farmi nemmeno andare su SAP.
Certamente importa se centomila persone perdono ognuna 20-25 minuti al giorno lavorativo senza aspettare nulla. Quelli sono milioni persiche potresti, invece di perdere, pagare come dividendi (o pagare salari più alti).
Certo, la maggior parte dei dipendenti è nella parte bassa della busta paga, ma anche nella parte inferiore il tempo è denaro .

Riesco a capire il motivo per cui importava, decenni fa. I computer erano molto più lenti e avevano molta meno memoria, quindi hai dovuto riflettere attentamente su queste cose.

Sembra sottovalutare la velocità con cui cresce N ^ 2. Diciamo che abbiamo un computer e il nostro algoritmo N ^ 2 impiega 10 secondi quando N = 10. Ora passa un nuovo processore che è 6 volte più veloce del nostro originale, quindi il nostro calcolo di 10 secondi ora è meno di due secondi. Quanto più grande può essere N e rimanere comunque in quel tempo di esecuzione di 10 secondi originale? Ora possiamo gestire 24 articoli, poco più del doppio. Quanto più veloce dovrebbe essere il nostro sistema per gestire un numero di articoli 10 volte superiore? Beh, dovrebbe essere 100 volte più veloce. I dati crescono piuttosto rapidamente e oltre a spazzare via i progressi dell'hardware del computer per gli algoritmi N ^ 2.

Non crederesti alla quantità di programmi aziendali di terze parti che utilizziamo sul posto di lavoro e molti di essi 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 nei costi, poiché alcuni programmi influenzano direttamente il numero di attività che posso svolgere durante un giorno, riducendo così la mia produttività e la quantità di elementi fatturabili. Quindi direi che è abbastanza importante anche per i programmi di business essere almeno abbastanza performanti da non essere la voce 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à parecchio il processo. Una causa potrebbe essere un accesso lento al database che semplicemente "attende un po '" ogni volta che l'utente esegue un'azione (compilare i dettagli della risoluzione, aggiornare le informazioni di lavoro o simili). Posso immaginare che ci sono casi in cui i programmi lenti possono persino influenzare cose più critiche, come i dettagli dei pazienti ospedalieri su casi di avvelenamento urgente - forse allergie ai medicinali o simili?

Molte delle altre risposte trattano l'argomento in modo abbastanza completo, quindi rimando a loro le ragioni e le motivazioni. Invece, voglio fare un esempio di vita reale per mostrare come una scelta algoritmica possa avere implicazioni reali.

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

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

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

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

Qui possiamo vedere che la scelta di un algoritmo ha avuto implicazioni reali. L'algoritmo sbagliato, benché valido per gran parte della vita del prodotto, può comunque avere impatti negativi lungo la strada.

Penso che tu stia interpretando la quantità di domande poste sulle prestazioni come indicazione che i requisiti di prestazione per le app aziendali sono importanti invece di riconoscerlo è difficile migliorare le prestazioni . Basta farlo funzionare può essere realizzato con tecniche di forza bruta, tentativi ed errori o copia e incolla del codice di esempio.

Chiunque può essere fortunato e continuare ad apportare modifiche fino a quando qualcosa non funziona più velocemente, 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 unico, pertanto è possibile porre una domanda specifica su un sito come StackOverflow. Inoltre, molti consulenti fanno i loro soldi potendo intervenire e risolvere questo tipo di problemi.

Dipende fortemente da come definisci "buone prestazioni". I tuoi algoritmi dovrebbero sempre utilizzare la migliore complessità possibile. Abusa le scappatoie per accelerare la tua gabbia media. Buffer e precarico / precompilazione ove possibile in un programma interattivo.

Esiste un'altra definizione di "buone prestazioni": l'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 passare del 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 lascialo stare e concentrati sui tuoi algoritmi.

A quel punto l'uso di Java / Haskell / C ++ diventa solo un'altra decisione di progettazione. Lo scricchiolio dei numeri può essere eseguito tramite OpenCL sulla 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 migliore utilizzo della cache del 20%. 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 più lenta del 10% di quanto potrebbe essere. Anche il 50% va bene (ma le persone iniziano 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 facilmente test per l'intero programma è molto più importante che essere un po 'più veloce nei lavori batch.

Abbastanza semplice: costo

Il mio precedente datore di lavoro aveva un sistema di gestione dell'apprendimento ospitato su server fisici come modello SaaS. L'heap di JVM è stato configurato su 2 GB per le macchine più vecchie 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 addetto alle prestazioni responsabile di rendere il sistema reattivo e scalabile. Hanno scoperto che c'erano alcuni dati che richiedevamo costantemente dal database. C'era anche una tabella a cui abbiamo aderito alla maggior parte delle query per recuperare una colonna. Questi dati raramente sono cambiati.

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

Ci sono state 2 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 nella cache di più.
2. Perché un sistema di gestione dell'apprendimento necessita di almeno 3 GB di RAM? Tutto ciò che invia query SQL, inviare reindirizzamenti per avviare corsi e valutare i progressi degli studenti attraverso i corsi.

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

Il mio attuale datore di lavoro ospita anche un sistema di gestione dell'apprendimento, ma lo ospita in modo leggermente diverso. La scalabilità è così scarsa che una singola installazione (suddivisa su 4 server virtuali con bilanciamento del carico) 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 racchiudono tutti i cicli della CPU, perdite di memoria, codice ridondante che fa la stessa cosa più volte. Abbiamo persino un'app interna costruita il cui unico scopo è riavviare i server quando non funzionano male. C'è un dipendente che mantiene quello strumento (insieme ad altre responsabilità).

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

Questo non ha funzionato economicamente come previsto. Tra hardware, licenze software e personale di supporto per la gestione dei server, abbiamo speso milioni ogni anno per evitare che uno sviluppatore impiegasse del tempo a profilare il codice.

Quando mi sono iscritto, sono stato reso responsabile della risoluzione dei 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à è notevolmente migliorata, con tempi di attività molto migliori. Siamo pronti per iniziare ad aumentare la densità. Inutile dire che il mio stipendio non è in alcun modo vicino a un milione (lo desidero!), Quindi spendere soldi per avermi messo a punto per ottimizzare il codice finirà per salvarci milioni all'anno.

TL; DR

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

Ho capito la tua domanda in questo modo: per ottenere prestazioni abbastanza buone (cioè gli utenti sono felici e il mio backend non si contorce), devo capire la teoria sulla complessità algoritmica?

Dipende da cosa intendi per "tipica" applicazione aziendale. In molti casi, in particolare i semplici sistemi di informazione simili a CRUD, la risposta sarebbe no. Per questi "semplicemente" (a volte è in realtà difficile) devi essere in grado di tracciare i colli di bottiglia delle prestazioni: ho perso un indice nel mio database? Devo inviare troppi dati sulla rete? Ho un orologio da $ 1.000 nel mio front-end angular.js? Si tratta di costruire un'architettura sonora, conoscere bene lo stack tecnologico ed evitare il non senso. Puoi farlo se sei un bravo artigiano, non necessariamente un informatico. Un altro modo di dire è che i ragazzi che hanno creato Oracle Query Optimizer si sono occupati della complessità algoritmica, devi solo usare correttamente ciò che ti hanno fornito.

Ora ci sono eccezioni. Se stiamo parlando di big data o machine learning, devi sapere cosa stai facendo e non solo usare gli algoritmi predefiniti a tua disposizione. Anche sul front-end, se inizi a creare visualizzazioni di dati avanzate, alcune di esse possono comportare un costo di complessità non lineare (ad es. Grafici a imposizione forzata).

Oggi queste eccezioni stanno diventando sempre più comuni e il mercato è piuttosto secco quando cerchi persone in grado di gestirle. Quindi: sì, puoi avere successo senza background informatico, ma ne avrai ancora di più con alcuni.

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