Perché c'è un'enorme differenza tra l' ottimizzazione delle prestazioni e la disattivazione completa della sicurezza
Riducendo il numero di GC, il loro framework è più reattivo e può funzionare (presumibilmente) più velocemente. Ora, l'ottimizzazione per il garbage collector non significa che non facciano mai una garbage collection. Significa solo che lo fanno meno spesso, e quando lo fanno, funziona molto velocemente. Questo tipo di ottimizzazione include:
- Ridurre al minimo il numero di oggetti che si spostano in uno spazio di sopravvivenza (ovvero che sono sopravvissuti ad almeno una raccolta di rifiuti) utilizzando piccoli oggetti a perdere. Gli oggetti che si sono trasferiti nello spazio dei sopravvissuti sono più difficili da raccogliere e una raccolta di rifiuti qui a volte implica il congelamento dell'intera JVM.
- Non allocare troppi oggetti per cominciare. Questo può ritorcersi contro se non stai attento, poiché gli oggetti di nuova generazione sono super economici da allocare e raccogliere.
- Assicurati che il nuovo oggetto punti a quello vecchio (e non viceversa) in modo che l'oggetto giovane sia facile da raccogliere, poiché non vi è alcun riferimento a loro che li farà conservare
Quando si ottimizza la performance, di solito si sintonizza un "hot spot" molto specifico ignorando il codice che non viene eseguito spesso. Se lo fai in Java, puoi lasciare che il garbage collector si occupi ancora di quegli angoli bui (dal momento che non farà molta differenza) ottimizzando molto attentamente per le aree che girano in un circuito ristretto. Quindi puoi scegliere dove ottimizzare e dove no, e così puoi concentrare i tuoi sforzi dove sono importanti.
Ora, se disattivi completamente la raccolta dei rifiuti, non puoi scegliere. È necessario disporre manualmente di ogni oggetto, mai. Quel metodo viene chiamato al massimo una volta al giorno? In Java, puoi lasciarlo essere, poiché il suo impatto sulle prestazioni è trascurabile (potrebbe essere OK lasciare che si verifichi un GC completo ogni mese). In C ++, stai ancora perdendo risorse, quindi devi prenderti cura anche di quel metodo oscuro. Quindi devi pagare il prezzo per la gestione delle risorse in ogni singola parte della tua applicazione, mentre in Java puoi concentrarti.
Ma peggiora.
Cosa succede se si dispone di un bug, diciamo in un angolo buio dell'applicazione a cui si accede solo il lunedì di luna piena? Java ha una forte garanzia di sicurezza. C'è poco o nessun "comportamento indefinito". Se si utilizza qualcosa di sbagliato, viene generata un'eccezione, il programma si interrompe e non si verifica alcun danneggiamento dei dati. Quindi sei abbastanza sicuro che nulla di sbagliato può accadere senza che te ne accorga.
Ma in qualcosa come D, puoi avere un cattivo accesso al puntatore o un buffer overflow e puoi corrompere la tua memoria, ma il tuo programma non lo saprà (hai disattivato la sicurezza, ricordi?) E continuerà a funzionare con il suo errato dati e fare cose piuttosto brutte e corrompere i tuoi dati, e tu non lo sai, e man mano che aumenta la corruzione, i tuoi dati diventano sempre più sbagliati, e poi improvvisamente si rompono, ed era in un'applicazione cruciale per la vita, e qualche errore è accaduto nel calcolo di un razzo, e così non funziona, e il razzo esplodere, e morire qualcuno, e la vostra azienda è in prima pagina di tutti i giornali e il vostro punto di sporgenza il dito a voi dicendo "Tu sono l'ingegnere che ci ha suggerito di utilizzare D per ottimizzare le prestazioni, come mai non hai pensato alla sicurezza?". Ed è colpa tua. Hai ucciso quelle persone con il tuo folle tentativo di esibizione.
OK, ok, il più delle volte è molto meno drammatico di così. Ma anche un'applicazione critica per le aziende o solo un'app GPS o, diciamo, un sito Web di assistenza sanitaria del governo può produrre alcune conseguenze piuttosto negative se si hanno bug. Usare una lingua che li prevenga completamente o fallisca rapidamente quando si verificano è di solito un'ottima idea.
C'è un costo per disattivare una sicurezza. Diventare nativi non ha sempre senso. A volte è molto più semplice e sicuro ottimizzare solo un po 'una lingua sicura che andare all in per una lingua in cui puoi spararti ai piedi alla grande. La correttezza e la sicurezza in molti casi vincono i pochi nano secondi che avresti eliminato eliminando completamente il GC. Disruptor può essere usato in quelle situazioni, quindi penso che LMAX-Exchange abbia fatto la scelta giusta.
Ma che dire di D in particolare? Hai un GC se vuoi per gli angoli bui e il sottoinsieme SafeD (che non conoscevo prima della modifica) rimuove il comportamento indefinito (se ricordi di usarlo!).
Bene, in quel caso è una semplice questione di maturità. L'ecosistema Java è pieno di strumenti ben scritti e librerie mature (meglio per lo sviluppo). Molti più sviluppatori conoscono Java che D (meglio per la manutenzione). Scegliere una lingua nuova e non così popolare per qualcosa di così critico come un'applicazione finanziaria non sarebbe stata una buona idea. Con un linguaggio meno conosciuto, se hai un problema, pochi possono aiutarti e le biblioteche che trovi tendono ad avere più bug poiché sono state esposte a meno persone.
Quindi il mio ultimo punto è ancora valido: se si desidera evitare problemi con conseguenze disastrose, attenersi a scelte sicure. A questo punto della vita di D, i suoi clienti sono le piccole start-up pronte a correre rischi folli. Se un problema può costare milioni, è meglio rimanere più avanti nella curva della campana dell'innovazione .