Che cosa causa cattive prestazioni nelle app consumer? [chiuso]

My Comcast DVR impiega almeno tre secondi per rispondere a ogni pressione del tasto del telecomando, rendendo il semplice compito di guardare la televisione un'esperienza frustrante di schiacciamento dei pulsanti. Il mio iPhone impiega almeno quindici secondi per visualizzare messaggi di testo e si arresta in modo anomalo ¼ delle volte in cui provo a visualizzare l'app per iPod; la semplice ricezione e lettura di un'e-mail richiede spesso più di un minuto. Perfino la navcom della mia macchina ha controlli molli e non rispondenti, spesso ingoiando input successivi se li faccio a meno di qualche secondo di distanza.

Si tratta di tutti i dispositivi di consumo finali con hardware fisso per i quali l'usabilità dovrebbe essere fondamentale, eppure falliscono tutti in termini di reattività e latenza di base. Il loro software è troppo lento .

Cosa c'è dietro questo? È un problema tecnico o sociale? Chi o cosa è responsabile?

È perché sono stati tutti scritti in lingue gestite, immerse nella spazzatura anziché in codice nativo? Sono i singoli programmatori che hanno scritto il software per questi dispositivi? In tutti questi casi gli sviluppatori di app sapevano esattamente quale piattaforma hardware stavano prendendo di mira e quali erano le sue capacità; non l'hanno preso in considerazione? È il tipo che va in giro a ripetere "l'ottimizzazione è la radice di tutti i mali", li ha portati fuori strada? Era una mentalità di "oh, sono solo altri 100 ms" ogni volta fino a quando tutti quei millisecondi si sommano in minuti? È colpa mia, per aver comprato questi prodotti in primo luogo?

Questa è una questione soggettiva, con nessuna singola risposta, ma sto spesso frustrato di vedere così tante risposte qui a dire "Oh, non preoccuparti per la velocità di codice, le prestazioni non importa" quando chiaramente ad un certo punto si fa questione di l'utente finale che rimane bloccato con un'esperienza lenta, non rispondente, terribile.

Quindi, a che punto le cose sono andate male per questi prodotti? Cosa possiamo fare come programmatori per evitare di infliggere questo dolore ai nostri clienti?

Buona domanda. Quello che vedo ogni giorno è questo.

Le persone lavorano su app di buone dimensioni. Mentre funzionano, i problemi di prestazioni si insinuano, proprio come i bug. La differenza è che i bug sono "cattivi" - gridano "trovami e correggimi". I problemi di prestazioni sono semplicemente lì e peggiorano. I programmatori spesso pensano "Bene, il mio codice non avrebbe un problema di prestazioni. Piuttosto, la direzione deve comprarmi una macchina più nuova / più grande / più veloce."

Il fatto è che se gli sviluppatori cercano periodicamente problemi di prestazioni (che in realtà è molto semplice ) potrebbero semplicemente eliminarli.

Invece, lo "stato dell'arte" è:

1. fare affidamento su aforismi come "evitare l'ottimizzazione prematura" e 90/10 hoo-haw.
2. parlare con coraggio della profilazione e talvolta effettivamente provarlo, spesso con risultati deludenti, come si vede in tutte le domande SO su di esso.
3. ricadere su buone congetture, mascherate da esperienza e conoscenza.

Ma davvero, questo è negativo. Per essere positivo, questo metodo funziona quasi sempre e non potrebbe essere più semplice. Ecco un esempio dettagliato .

Questo non è un problema tecnico, è un problema di marketing e gestione.

A questo punto potresti alzare gli occhi al cielo, ma per favore abbi pazienza con me.

Ciò che un'azienda vende è il suo "prodotto", e le persone che definiscono ciò che sono i "product manager". Nelle aziende tecnologiche, molte altre persone pesano su questo: esperti dell'esperienza utente, Yadda Yadda. Ma alla fine, i responsabili del prodotto sono responsabili di scrivere le specifiche per ciò che l'utente dovrebbe ottenere.

Quindi, prendiamo il tuo DVR Comcast. Idealmente, le cose funzionerebbero così:

1. Il responsabile del prodotto scrive una specifica: "Quando un utente preme un pulsante sul telecomando ed è entro 25 piedi dal DVR, il DVR deve rispondere alla stampante entro 250 millisecondi".
2. La gente tecnica costruisce l'hardware, scrive il software incorporato, ecc.
3. I tester del QA approvano che il sistema soddisfi le specifiche o lo rimandano al team tecnico per una correzione.

Certo, molte cose possono andare storte:

• Il product manager non inserisce la risposta del pulsante nelle specifiche
• La gente di QA fa un lavoro mediocre di test contro le specifiche
• Qualcuno ha selezionato tecnologie che non consentono di soddisfare le specifiche, quindi il requisito viene superato
• Lo staff tecnico è a corto di personale o qualcuno ha accelerato il programma e alcuni manager dicono "Dimentica la reattività: completa questa altra funzionalità".
• Il product manager non pubblica i requisiti di reattività fino a così tardi nel gioco, non può essere soddisfatto entro la data di spedizione
• La direzione decide di non inviare nulla per i test di qualità fino a così tardi, l'accelerazione del codice lento destabilizzerebbe il prodotto

Hai visto tutti i programmatori imperfetti lì dentro? Non ce n'erano.

Non sto dicendo che non ci assumiamo alcuna responsabilità per le cattive prestazioni - spesso, è altrettanto facile e veloce scrivere codice buono, robusto ed efficiente come è scrivere spazzatura.

Ma davvero, se la gestione del prodotto e il personale addetto al controllo qualità sono tutti addormentati al volante, noi programmatori non possiamo farcela.

FWIW, sono completamente d'accordo sulle interfacce abissali della maggior parte dei prodotti di consumo. Scrivo il codice dell'interfaccia utente da circa 25 anni e cerco l'eleganza e la semplicità. In realtà è un problema perché ci penso così tanto, ora sono pessimo nel capire interfacce utente mal progettate, quindi la mia povera moglie finisce per far funzionare la maggior parte dei dispositivi nel nostro media center.

Perché i programmatori non sono perfetti.

Sono un programmatore di cose incorporate. Parte del mio codice non è perfetto. Gran parte del mio codice incorporato è veloce.

Risolvere i problemi di prestazioni alla fine di un progetto è molto difficile.

A volte, per mantenere le cose semplici (e quindi testabili, sviluppabili in tempo realistico, non fatalmente buggy) mettiamo a strati le cose, come l'input remoto a un "servizio" che non fa parte dell'applicazione principale. Risultato finale, latenza. L'alternativa è mettere tutto in un'applicazione monolitica è un disastro difettoso in C o C ++ (i due linguaggi incorporati più comuni).

A volte il tuo dispositivo incorporato ha un programmatore di processo che non fa ciò che desideri come utente. Dannatamente difficile da risolvere come sviluppatore incorporato.

La complessità causa il ritardo, a causa della latenza sulla stratificazione. Hai chiesto le funzionalità. Prova un Nokia davvero vecchio, come il vecchio 3210. Interfaccia utente veloce e veloce. Non molte funzionalità.

Sto sostenendo che gli sviluppatori non diventano più intelligenti, quindi l'hardware più veloce viene assorbito dalle astrazioni per impedire che le funzionalità si uccidano a vicenda. (O no, nel caso del tuo iPhone)

Le prestazioni dell'interfaccia utente devono essere un requisito da testare man mano che la progettazione avanza.

Se non specificato, lo sviluppatore si abituerà. Lo facciamo tutti. "Il mio bambino non è brutto"

E non sono i linguaggi GC; Java in tempo reale incorporato è così veloce che fa paura. (Embedded Python invece è un cane totale)

Scrivo un programma che legge gli interruttori sugli ingressi digitali come interfaccia utente. Devo ancora rimbalzare l'interruttore, quindi azionare rapidamente l'interruttore non funziona, perché il de-rimbalzo è un paio di livelli. Idealmente avrei una logica di de-rimbalzo nella parte inferiore dello stack del firmware, ma non è così che funziona l'hardware.

Alcuni lettori DVD eseguono semplicemente uno script di "espulsione" per espellere. È possibile che il DVR abbia adottato questo approccio per mantenere sani i costi di sviluppo. Quindi risparmi su CPU o RAM e fa schifo.

È perché sono stati tutti scritti in lingue gestite, immerse nella spazzatura anziché in codice nativo?

No. Il codice lento funzionerà male a prescindere. Certo, un linguaggio particolare può introdurre alcune classi di problemi mentre risolve gli altri. Ma i bravi programmatori sono abbastanza in grado di trovare soluzioni alternative con abbastanza tempo.

Sono i singoli programmatori che hanno scritto il software per questi dispositivi?

In parte. In molti casi è abbastanza probabile almeno un fattore che contribuisce. Questo è uno sfortunato effetto collaterale di un settore in cui i buoni programmatori sono molto richiesti e scarsamente disponibili. Anche i divari tra i vari livelli di abilità tecnica possono essere piuttosto ampi. Quindi è ovvio che a volte i programmatori incaricati di implementare determinati software potrebbero essere congratulati solo per farlo funzionare (in un certo senso ).

In tutti questi casi gli sviluppatori di app sapevano esattamente quale piattaforma hardware stavano prendendo di mira e quali erano le sue capacità; non l'hanno preso in considerazione?

In parte. Per cominciare, la piattaforma hardware esatta probabilmente non è nota, poiché spesso viene negoziata con vari produttori in parallelo durante lo sviluppo del software. In effetti, dopo il rilascio iniziale possono esserci anche piccole (ma non necessariamente insignificanti) modifiche all'hardware sottostante. Tuttavia, concordo sul fatto che saranno note le capacità generali.

Parte del problema è che il software probabilmente non è sviluppato sull'hardware, è fatto con gli emulatori. Ciò rende difficile tenere conto delle prestazioni reali del dispositivo anche se gli emulatori sono precisi al 100%, cosa che non lo sono.

Ovviamente ciò non giustifica realmente i test insufficienti sull'hardware prototipo appropriato prima del rilascio. Quella colpa probabilmente è al di fuori del controllo dev / qa.

È il tipo che va in giro a ripetere "l'ottimizzazione è la radice di tutti i mali", li ha portati fuori strada?

No. Sono abbastanza certo che non lo ascoltano comunque; altrimenti non verrebbe citato erroneamente così spesso (dovrebbe essere " ottimizzazione prematura ..."). :-D

È più probabile che troppi programmatori prendano uno dei 2 estremi per quanto riguarda l'ottimizzazione.

• O lo ignorano completamente.
• Oppure si ossessionano con le minuzie che non hanno nulla a che fare con i reali requisiti di prestazione. L'effetto netto è che il budget si esaurisce e il codice è troppo offuscato per ottimizzare in modo sicuro i problemi di prestazioni reali .

Era una mentalità di "oh, sono solo altri 100 ms" ogni volta fino a quando tutti quei millisecondi si sommano in minuti?

Possibilmente. Ovviamente se Sleep(100)è stato usato come equivalente della carta velina utilizzata per rallentare l'emorragia di un arto reciso, allora ci si devono aspettare problemi. Tuttavia, sospetto che il problema sia più sottile di così.

Il fatto è che l'hardware di elaborazione moderno (compresi i dispositivi integrati) è molto più veloce di quanto le persone attribuiscano loro credito. Molte persone, anche i programmatori "esperti" non riescono ad apprezzare quanto siano veloci i computer. 100ms è un tempo lungo - un tempo molto lungo . E come accade, questo "tempo molto lungo" taglia 2 modi:

• Il primo è che i programmatori si preoccupano inutilmente delle cose che un computer fa in modo estremamente rapido. (Accade così che sia stata proprio una tale preoccupazione " incrementare un valore 300 volte al secondo " che mi ha portato qui in primo luogo.)
• Il secondo è che a volte non riescono a mostrare la dovuta preoccupazione quando le cose richiedono molto tempo (sulla scala di calcolo). Così:
  • se ignorano gli effetti della latenza quando comunicano su una rete o con un dispositivo di archiviazione;
  • se ignorano l'impatto di un thread bloccato e in attesa di un altro thread;
  • se dimenticano che, poiché i computer funzionano così rapidamente, è molto in grado di ripetere un'attività molto più spesso di quanto dovrebbe, senza che lo sviluppatore sia a conoscenza di un problema
  • ... se si verifica una combinazione di tali sviste, una routine verrà eseguita inaspettatamente molto lentamente (sulla scala dei tempi di calcolo). Alcune ripetizioni e sarà persino evidente dagli umani, ma potrebbe essere difficile da definire perché centinaia di cose interconnesse corrono rapidamente da sole.

È colpa mia, per aver comprato questi prodotti in primo luogo?

Sì, sicuramente. Bene, non tu personalmente ma i consumatori in generale. I prodotti sono venduti (e acquistati ) dalle liste di controllo delle funzionalità. Troppi consumatori richiedono prestazioni migliori.

Per illustrare il mio punto: l'ultima volta che ho voluto acquistare un telefono cellulare, il negozio non poteva nemmeno offrire un modello demo con cui giocare in negozio. Tutto ciò che avevano erano gusci di plastica con adesivi per mostrare come sarebbe stato lo schermo. Non puoi nemmeno avere un'idea del peso del genere - per non parlare delle prestazioni o dell'usabilità. Il mio punto è che se un numero sufficiente di persone si opponesse a quel modello di business e votasse con i loro portafogli per esprimere la propria obiezione, saremmo un piccolo passo nella giusta direzione.

Ma non lo fanno, quindi non lo siamo; e ogni anno i nuovi telefoni cellulari funzionano più lentamente su hardware più veloce.

(Le domande non sono state poste.)

• La colpa è del marketing? In parte. Hanno bisogno di date di uscita. E quando incombe la data, la scelta tra "farlo funzionare" e "renderlo più veloce" è un gioco da ragazzi.
• I responsabili delle vendite sono i responsabili? In parte. Vogliono più funzionalità nella lista di controllo. Promuovono elenchi di funzionalità e ignorano le prestazioni. (A volte) fanno promesse non realistiche.
• I responsabili sono i responsabili? In parte. I manager inesperti possono commettere molti errori, ma anche i manager molto esperti possono (giustamente) sacrificare il tempo per risolvere i problemi di prestazioni a favore di altre preoccupazioni.
• Le specifiche sono da biasimare? In parte. Se qualcosa viene lasciato fuori specifica, è molto più facile "dimenticarsene" in un secondo momento. E se non è espressamente indicato, qual è l'obiettivo? (Anche se credo personalmente che se una squadra è orgogliosa del proprio lavoro, si preoccuperebbe delle prestazioni a prescindere.)
• L'educazione è la colpa? Può essere. L'istruzione probabilmente sarà sempre in secondo piano. Certamente disapprovo l '"educazione" che sforna rapidamente i principianti con una comprensione superficiale dello sviluppo del software. Tuttavia, l'educazione sostenuta dalla teoria e instillando una cultura dell'apprendimento non può essere cattiva.
• La colpa è degli aggiornamenti? In parte. Nuovo software, vecchio hardware è davvero un destino allettante. Anche prima che venga rilasciata la versione X, X + 1 è in fase di pianificazione. Il nuovo software è compatibile, ma il vecchio hardware è abbastanza veloce? È stato testato? Una particolare correzione delle prestazioni può essere inserita nel nuovo software, incoraggiando un aggiornamento software sconsigliato.

Fondamentalmente, credo che ci siano molti fattori che contribuiscono. Quindi, sfortunatamente, non esiste un proiettile d'argento per ripararlo. Ma ciò non significa che sia tristezza e tristezza. Ci sono modi per contribuire a migliorare le cose.

Quindi, a che punto le cose sono andate male per questi prodotti?

IMHO non possiamo davvero identificare nessun singolo punto. Ci sono molti fattori che si sono evoluti nel tempo.

• Contatori di fagioli: riduzione dei costi, tempistica del mercato. Ma poi avremmo fatto i progressi che abbiamo ottenuto senza la pressione?
• Elevata domanda e scarsa offerta di personale qualificato nel settore. Non solo programmatori, ma anche manager, tester e persino venditori. La mancanza di abilità ed esperienza porta ad errori. Ma poi porta anche all'apprendimento.
• Tecnologia all'avanguardia. Fino a quando una tecnologia non matura, morde regolarmente in modi inaspettati. Ma poi di nuovo spesso ha offerto una serie di vantaggi in primo luogo.
• Complicazione composta. Nel tempo, l'industria si è evoluta: aggiungendo più strumenti, tecnologie, livelli, tecniche, astrazioni, hardware, lingue, variazioni, opzioni. Ciò rende in qualche modo impossibile avere una "piena" comprensione dei sistemi moderni. Tuttavia, siamo anche in grado di fare molto di più in un tempo molto più breve di conseguenza.

Cosa possiamo fare come programmatori per evitare di infliggere questo dolore ai nostri clienti?

Ho alcuni suggerimenti (sia tecnici che non tecnici) che possono aiutare:

• Per quanto possibile, usa il tuo prodotto. Non c'è niente come l'esperienza di prima mano per rivelare cose imbarazzanti, lente o scomode. Tuttavia dovrai evitare consapevolmente di evitare le carenze dovute alla "conoscenza privilegiata". Ad esempio, se non hai problemi a sincronizzare i contatti perché lo fai con uno script Python backdoor, non stai usando "il prodotto". Il che fa apparire il punto successivo ...
• Ascolta i tuoi utenti (preferibilmente di prima mano, ma almeno di seconda mano tramite supporto). So che i programmatori (in genere) preferiscono rimanere nascosti ed evitare l'interazione umana; ma ciò non ti aiuta a scoprire i problemi che altre persone incontrano durante l'utilizzo del tuo prodotto. Ad esempio, potresti non notare che le opzioni del menu sono lente, perché conosci tutte le scorciatoie e le usi esclusivamente. Anche se il manuale documenta completamente tutte le scorciatoie, alcune persone preferiranno comunque i menu, nonostante siano insopportabilmente lente.
• Sforzati di migliorare le tue abilità e conoscenze tecniche su base continua. Sviluppa l'abilità per analizzare criticamente tutto ciò che impari. Rivaluta regolarmente le tue conoscenze. In alcuni casi, preparati a dimenticare ciò che pensavi di sapere. Il che fa apparire ...
• Alcune tecnologie / tecniche possono essere molto complicate, portando a sottili malintesi e implementazioni errate. Altri, attraverso l'evoluzione della conoscenza comune o degli strumenti disponibili, potrebbero cadere in disgrazia o favore (ad es. Singletons). Alcuni argomenti sono così complicati che generano un gruppo di "esperti di hoc-pocus" che propagano un enorme corpus di disinformazione. Un mio particolare bugbear è la disinformazione che circonda il multi-threading. Una buona implementazione multi-thread può migliorare significativamente l'esperienza dell'utente. Sfortunatamente molti approcci disinformati al multi-threading ridurranno significativamente le prestazioni, aumenteranno i bug irregolari, aumentano i rischi di dead-lock, complicano il debugging ecc. Quindi ricorda: solo perché lo ha detto un "esperto", non lo rende vero.
• Assumere la proprietà. (No sul serio, non sto giocando a bingo nella sala del consiglio.) Negoziare con gestori, proprietari di prodotti, addetti alle vendite per caratteristiche prestazionali che hanno la precedenza su alcuni elementi della checklist. Richiedi specifiche migliori. Non infantilmente, ma ponendo domande che inducono le persone a pensare alle prestazioni.
• Sii un consumatore esigente. Scegli il telefono che ha meno funzioni ma è più veloce. (CPU non più veloce, UI più veloce.) Quindi vantati ! Più consumatori iniziano a richiedere prestazioni elevate, più contatori di bean inizieranno a preventivare il budget.

Il tuo primo errore, e probabilmente il motivo per cui hai ottenuto un voto negativo, merita l'esagerazione palesemente evidente. Ti aspetti davvero di credere che iPhone e iPad siano così male.

Alla fine il cliente è responsabile. Si riduce ai costi, a ciò che il cliente è disposto a pagare e a ciò che riceve in cambio. Se scelgono funzionalità piuttosto che velocità, ecco cosa ottengono. Se scelgono il prezzo sulla velocità, questo è ciò che viene costruito e venduto. Se l'immagine del marchio è più importante ..... Alla fine il cliente decide con il proprio portafoglio, cosa è importante e cosa no. Puoi scegliere di essere una puttana del marchio e acquistare prodotti perché tutti gli altri lo fanno, o essere un pensatore indipendente, guardare dietro il gloss e l'hype di marketing e acquistare qualcosa che soddisfi le tue esigenze.

Stai incolpando i programmatori. Hanno scritto il codice, certo, ma non hanno definito e non dovrebbero definire i requisiti dei clienti, l'hardware, il costo della distinta base, il costo di ricerca e sviluppo, il budget di marketing ..... tutto ciò che serve per realizzare un prodotto , che non è un software.

Le tecnologie utilizzate, le lingue utilizzate ecc. Non hanno nulla a che fare con questo. Cattivi contro buoni sviluppatori, niente a che fare con esso. Qualsiasi programmatore decente può far funzionare un pezzo di codice più velocemente, essere più reattivo, essere il massimo che potrebbe. La mia esperienza è che i programmatori decenti non fanno fallire il business quando vengono lasciati a prendere le decisioni, mentre quelli decenti si lamentano di quanto "meglio" dovrebbe "essere".

L'ottimizzazione prematura a volte è negativa, ma non quando è richiesta per una buona esperienza utente o una buona durata della batteria in un sistema sufficientemente limitato. L'errore è colpa di dare una priorità più alta alla pulizia dell'ingegneria del software gestibile rispetto alla cottura in qualunque cosa serva per fornire una buona esperienza utente e una durata della batteria decente come una priorità più alta all'inizio di un progetto, anche se è molto più difficile da mantenere e corto circonda alcuni stack e metodologie di software ben progettati.

Se hai un iPhone 3G, Apple ha rilasciato un paio di aggiornamenti del sistema operativo che sono stati ottimizzati solo per i dispositivi più recenti. Gli aggiornamenti successivi del sistema operativo per il 3G potrebbero fornire prestazioni leggermente migliori sul 3G.

Il DVR impiega così tanto tempo a cambiare canale perché deve prima scaricare i dati bufferizzati, quindi mettere in coda un altro buffer pieno di dati per il nuovo canale che si sta guardando. Molto probabilmente questo buffer è memorizzato sul disco rigido, quindi queste operazioni richiedono tempo (inoltre può riempire il buffer solo in tempo reale). Con un DVR non stai mai guardando la programmazione "live", è sempre ritardata (non a caso, è ritardata allo stesso tempo del ritardo percepito quando si cambia canale). Questo può essere facilmente verificato guardando un programma sportivo mentre lo ascolti alla radio.

Penso che il motivo sia che la maggior parte delle app rivolte ai consumatori sono controllate e commercializzate da persone che non conoscono nulla del software e assumono sviluppatori in base ai loro curriculum o alle raccomandazioni di alcuni gestori del nulla, al contrario delle loro effettive competenze e conoscenze .