Meno codice o meno operazioni [chiuso]

Non esiste una scelta migliore in generale . La leggibilità del codice e le prestazioni del sistema sono due obiettivi validi e, se sono in disaccordo, deve conoscere i punti di forza di queste due forze nella tua situazione particolare prima di decidere. Per dire "quando la leggibilità e le prestazioni sono in disaccordo, scegli sempre le prestazioni (o la leggibilità)" sarebbe una terribile semplificazione eccessiva che porta a decisioni terribili se seguite ciecamente.

Per prendere una buona decisione, considereresti queste forze nel contesto delle tue reali esigenze. Ad esempio:

• Il comportamento dell'interfaccia utente, in particolare per quanto riguarda il dipingere il puntatore del mouse, è piuttosto sensibile alla velocità. Potrebbe non influire sul throughput effettivo di un'applicazione molto o del tutto, ma la impressione della velocità è vitale per una buona esperienza utente: i millisecondi del ritardo di feedback possono contribuire all'antipatia subconscia di un sistema. (Consulta i professionisti dell'esperienza utente per ottenere dati più precisi, ma sono incredibilmente piccoli.) Quindi in questo caso, le prestazioni potrebbero essere relativamente importanti piuttosto che "belle da avere".
• Allo stesso tempo, il codice di rendering grafico è una parte piuttosto fondamentale di un grande sistema. Sicuramente vuoi che sia corretto e solido come una roccia: disegnare male qualcosa nell'interfaccia utente può lasciare un'impressione ancora peggiore del ritardo di feedback. Ciò pone un vantaggio sulla manutenibilità e ciò significa che anche la leggibilità è importante.
• Ma il rendering di sprite, icone o qualsiasi altra cosa siano le primitive di basso livello è (spero) un problema relativamente piccolo e contenuto. Una volta implementato, potrebbe non richiedere un miglioramento continuo come fanno le regole o le interfacce aziendali (quanto spesso una nuova modalità di input arriva a lungo che sfida le tastiere e i mouse stabiliti?), Quindi forse puoi farla franca ottimizzando cavolo fuori dal tuo codice e poi mettici un coperchio. Ciò significherebbe più opportunità di ottimizzazione e meno pericolo di dover disfare i tuoi trucchi intelligenti la prossima volta che avrai bisogno di cambiare il comportamento a basso livello.

Questo non vuol dire che dovresti ottimizzare per la velocità, in questo caso o in generale, solo perché ho chiamato due oggetti Pro Speed e un oggetto di manutenzione pro. Questi sono solo esempi del tipo di domande che devi chiedere per prendere la decisione giusta in base alle circostanze. Inoltre, è necessario quantificare gli effetti che si stanno confrontando, ad es. tramite test di usabilità e metriche di profilazione. Un grande svantaggio può essere sufficiente per annullare i vantaggi di un intero gruppo di piccoli clienti.