Perché la gente dice ancora che Java è lento? [chiuso]

Per molto tempo in SO e in altri luoghi Java ha la reputazione di essere lento. Dalle battute a molti commenti in domande e risposte, la gente crede ancora che Java sia lento basandosi esclusivamente sull'esperienza con esso negli anni '90.

Questo è il mio problema: abbiamo smentito (la maggior parte) delle ragioni per cui le persone credono che Java sia lento. Al di fuori delle piccole cose, Java è piuttosto veloce.

Allora perché la gente rifiuta ancora di credere che Java sia veloce adesso? Fa parte della loro mentalità che qualcosa che non è C / C ++ è lento? È perché le persone non controllano nel tempo? È perché le persone sono solo di parte?

Sono le applicazioni. Come si nota, noi abbiamo dimostrato, più e più volte, che in scenari inventati codice Java in grado di soddisfare o addirittura battere le prestazioni delle cosiddette lingue "performanti" come C, C ++, Lisp, VB6, o JavaScript. E quando presentati con tali prove, la maggior parte degli avversari sani di mente e aperti apriranno la testa per la vergogna e prometteranno mai più di diffondere tale calunnia.

... ma poi accendono Eclipse, NetBeans o Guiffy, abilitano il supporto Java nel loro browser o provano a eseguire un'app sul loro telefono preferito. E aspettano che diventi reattivo ...

... e aspetta ...

... e aspetta ...



... e aspetta ...







... e aspetta ...











... e ...




... cosa ho promesso di non fare mai più ? Scusa, devo essermi appisolato ...

Questa domanda funziona su premesse false: dove conta, Java è ancora lento. Dove conta sono algoritmi pesanti di calcolo su grandi set di dati. Certo, questi possono essere ottimizzati, a volte per essere alla pari con il codice C / C ++, ma solo a costo di modularità e genericità. Il codice C ++ efficiente può essere progettato per essere generico e utilizzabile come libreria per scopi generici. Codice Java non può. Basta osservare il Array.sortmetodo fortemente ottimizzato , che utilizza diverse implementazioni per tutti i tipi fondamentali e la cui variante di oggetto è ancora molto più lenta del generico di C ++ sortperché questi oggetti devono inviare dinamicamente confronti di uguaglianza.

Concesso, le ottimizzazioni just in time eseguite dal motore HotSpot possono effettivamente prevedere l'obiettivo di queste chiamate virtuali e tentare di inline. Ma questo è ancora più lento della chiamata direttamente incorporata che viene inviata all'interno del sortmetodo C ++ .

Un mio ex collega ha fatto benchmark comparativi di un problema su enormi set di dati ( conteggio q -gram utilizzando forme dinamiche) con un'implementazione C ++ basata su modelli e un'implementazione Java orientata agli oggetti. Il codice Java era ordini di grandezza più lenti del codice C ++.

Naturalmente questo sta confrontando le mele con le arance. Ma il punto è che l'implementazione Java è stata la migliore implementazione possibile (in termini di prestazioni, dato il grado di modularità richiesto per una libreria), così come l'implementazione C ++.

Sfortunatamente, i dati di riferimento non sono disponibili gratuitamente, ma altri hanno trovato numeri simili quando si confrontano le spese generali dell'astrazione di runtime. Ad esempio, Scott Meyers scrive in Effective STL sull'overhead della qsortfunzione generica di C :

L'ordinamento di C ++ praticamente mette sempre in imbarazzo il qsort di C quando si tratta di velocità. [...] In fase di esecuzione, sort effettua chiamate in linea alla sua funzione di confronto ... mentre qsort chiama la sua funzione di confronto tramite un puntatore. [...] Nei miei test su un vettore di un milione di doppi, [sort] ha funzionato fino al 670% più veloce ...

Perché è lento ... in alcune applicazioni. Le applicazioni desktop devono essere reattive dall'inizio e l'overhead di avvio viene considerato lento.

D'altra parte, se si esegue un server, non importa se c'è un po 'di riscaldamento (analisi e compilazione JIT): lo si fa una volta sulla luna blu, quindi il più delle volte non può essere considerato del tutto lento.

Direi che perché la gente l'ha incontrato per la prima volta, è stato lento. Sulla base di ciò, ne hanno fatto un'impressione. È improbabile che quell'impressione cambi se non la usano e non la usano a causa di quella impressione - è un circolo vizioso.

Devo ammetterlo, ho avuto l'impressione che Java fosse lento, e sì, era dalla mia precedente esposizione ad esso. Ora sono passato a diverse lingue e da allora ho avuto un'esposizione estremamente limitata a Java. Di conseguenza, la mia opinione non è cambiata molto.

Perché ci vuole una generazione per cambiare le percezioni delle persone su un prodotto

Non ha nulla a che fare con la velocità con cui Java diventa. Nella mente delle persone Java è un identificatore const associato alla parola "lento". C'è poco, niente che tu o Oracle potete fare al riguardo.

Sii felice che Oracle non abbia distrutto (ancora) la cultura della programmazione Java facendo qualcosa di avventato o stupido . Come addebitare costi di licenza eccessivi per usarlo. O citare in giudizio persone basate su brevetti software precedentemente di proprietà di Sun. ::sospiro::

Odio essere il presuntuoso qui ma, a meno che Oracle e Google non risolvano la lotta di Java a condizioni vantaggiose, o Google sia costretta ad acquistare Java e lo rende una piattaforma open source "corretta", Java è sulla buona strada per essere il bambino su il parco giochi che ha i pidocchi. IE, nessuno vorrà toccarlo con un palo da 20 piedi.

Nota: solo per essere chiari, quando dico generazione, parlo in termini di persone e non di computer. IE, fino a quando le persone che detengono quella percezione muoiono di vecchiaia o sostituite da una generazione più giovane la percezione resterà vera. Pensa in termini di 5 decenni e non di 5 anni.

Uno dei motivi è che le persone si fidano di ciò che gli altri dicono invece di ciò che vedono .

Secondo quanto mi è stato detto quando ho iniziato a programmare, Java è "più lento" di C ++ e il motivo per cui Java potrebbe essere usato è perché è "comodo e facile". Si ritiene comunemente che Java offra sicurezza e praticità a scapito delle prestazioni. Anche quando in seguito viene inventato C # le persone credono che sia più veloce di Java perché è "nativo".

Ma la verità che la gente vede senza percepirlo, è che, l'eclissi, l'IDE che è costruito con Java, è assolutamente l'IDE PIÙ VELOCE della classe. Ho usato quasi tutti i principali IDE di stream, quelli di MS e GNU, Borland ..., eclipse è il re assoluto degli IDE, in gran parte a causa della sua velocità.

Un altro motivo è il lungo tempo di avvio .

Java non è adatto per lo sviluppo di una piccola app che rimane nella barra delle applicazioni, consuma un po 'di memoria, apre una finestra di dialogo che ti ricorda di fare una pausa; o un blocco note che usi per aprire un file di testo, leggerlo e chiuderlo. Dovrebbe essere usato su qualcosa di GRANDE, come un web server che è sempre lì, fare un uso ottimizzato della tua risorsa informatica, rispondere a milioni di richieste ogni ora. O un IDE come eclipse che gestisce migliaia di file dell'area di lavoro. Non sai che la tua app Java è veloce fino a quando non viene eseguita per almeno diverse ore, credo.

@bigown "Perché la gente dice ancora che Java è lento?"

Perché sono stupidi. Perché non hanno esperienza lavorativa, ma pensano di essere l'incarnazione vivente di Dikjstra o la seconda venuta di Linus Torvald, oh non lo so. Le ragioni per dire una cosa così ritardata sono così tante, ma di solito stupidità, fanboyismo soggettivo insensato e puttana dell'attenzione emotiva sembrano essere dietro di loro.

Disettiamo questo in modo che tu possa vedere la verità di quello che ho appena detto sopra:

Innanzitutto, ciò che è lento, in quale contesto, per cosa, in quali condizioni, con quale scopo ingegneristico / scientifico / commerciale (per dire che fa schifo non è uno di questi). Chiunque dica "X è lento" per qualsiasi tecnologia X, o semplicemente "X è Y", dove Y è un tipo di affermazione negativa, senza rispondere a nessuna delle domande precedenti dovrebbe essere respinto come uno sciocco. Dichiarazioni del genere non hanno un posto nell'ingegneria. In politica e nelle chat room giovanili forse, ma non in ingegneria.

In secondo luogo, la maggior parte di questi sciocchi sbagliati piangono sul fatto che Java sia lento perché ZOMG, la loro eclissi impiega un'eternità per accendersi (accidenti, carica la cosa con tutti i plug-in e indovina cosa succede). per ottimizzare jvm affinché eclipse funzioni velocemente (o per qualsiasi applicazione Java del caso). Cioè, non hanno idea dell'ottimizzazione delle prestazioni, che è una realtà non solo per Java, ma per qualsiasi sistema non banale, sia esso hardware o software. Quindi proprio lì, si disarmano per qualsiasi validità tecnica nel fare dichiarazioni così insensate.

Terzo, consideriamo a cosa serve la maggior parte dello sviluppo Java: back-end OLTP prima di tutto; sistemi di monitoraggio al secondo posto. Entrambi i tipi di sistema sono destinati a funzionare in cluster e a funzionare ininterrottamente per settimane, se non per mesi. Importa davvero che la tua piccola app per eclissi o giocattolo impieghi un minuto o due per caricarsi quando lo scopo delle app REAL Java è di funzionare per lunghi periodi di tempo? Contesto, persone, contesto.

Infine, la spina dorsale di OLTP su Google ed Ebay funziona su Java. Lo prenderei come prova per contraddizione che Java non è lento (almeno per le condizioni che contano, non per piccoli esperimenti giocattolo, parametri di riferimento e prove annecdotali non verificabili fatte specificamente allo scopo di dire "X è lento, fa schifo".

C'è ingegneria e c'è fanboyismo. Indovina a quali dichiarazioni di categoria simili appartengono?

Perché lo è, possiamo chiudere questo argomento una volta per sempre?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [scorri verso il basso fino alle tabelle, Java è 3,7-12,6 volte più lento del C ++, ricerca dei dipendenti di Google]

PS: In caso contrario, nominami almeno un'app Java scattante per iniziare, non ne ho mai vista una prima.

TMHO, ciò è dovuto al tempo necessario per avviare la VM nel browser. Se un'applicazione si avvia lentamente, la gente lo ricorderà solo. Perché, il tempo di inizio lungo è davvero fastidioso. Veramente. Uno dei miei colleghi mi ha detto che non usa Firefox perché è troppo lento. (?!?). Ma, sì, ok, su Windows, Firefox impiega molto tempo a mostrarsi. Secondo lui, questa app è lenta, ha pensato alla sua velocità generale.

Lento rispetto a cosa? Sto pensando di passare dal normale Ruby a JRuby (ruby basato su Java) perché ho sentito che è più veloce.

Le opinioni sono opinioni e i fatti sono fatti.

Ecco un fatto tratto da Google Code Jam, che probabilmente sfida i programmatori a risolvere problemi informatici difficili in un breve periodo di tempo, il che significa che le prestazioni del linguaggio che usano svolgono un ruolo importante:

Nelle passate edizioni (2009, 2010, 2011), circa il 75% dei programmatori che erano arrivati ​​ai round finali utilizzava C ++, invece di circa il 15% utilizzando Java.

Fonte -> http://www.go-hero.net/jam/

Intorno al 1997 ho usato un HP Vectra VE (200 MHz) e Windows 95. La maggior parte delle applicazioni funzionava molto velocemente su questo, ma poi ho provato alcune applicazioni scritte in Java (IDE, se ricordo bene). Erano molto lenti, almeno le parti della GUI. Ci sono voluti molto tempo per avviarsi e gli elementi della GUI (ad esempio i menu) non erano molto reattivi - c'erano ritardi nel feedback visivo. Inoltre, poiché le applicazioni della GUI Java avevano (hanno) un aspetto piuttosto distintivo, ho imparato ad associare questo aspetto (e Java) a scarse prestazioni.

Dipende da cosa intendi come lento.

Prima di tutto, java ha fatto molti progressi di recente ed è molto veloce nella maggior parte dei casi. Ma :

• Java è lento all'avvio, perché devi caricare la JVM prima di fare qualsiasi cosa.
• Alcune funzionalità di sicurezza possono uccidere le prestazioni in alcuni casi. Il controllo associato con accesso casuale è un esempio.
• Fai qualcosa di veramente veloce in Java richiede di lavorare contro la JVM (per sfruttare la linea della cache per esempio).
• La mancanza di metaprogrammazione implica una penalità in fase di esecuzione con ogni astrazione, quindi le prestazioni arrivano al costo del design in molti casi.
• Java difficilmente può garantire vincoli in tempo reale - in base alla progettazione - e questo potrebbe essere considerato "lento" da alcune persone.

A proposito, java è, in alcuni casi, più veloce del C / C ++ alla vaniglia. Ma queste lingue ti danno gli strumenti per modificarle.

Java è un linguaggio di programmazione volto alla produttività. Ora è abbastanza veloce per la maggior parte delle applicazioni, ma non è sufficiente per alcuni altri.

In generale, la lentezza di Java è un argomento abusato perché nella maggior parte dei casi è irrilevante.

Il semplice codice Java canonico tende a essere alla pari o più veloce del semplice codice canonico C / C ++ / D. Il codice semplice e canonico tende a eseguire molte allocazioni di memoria inutilmente, non è particolarmente sintonizzato su nessuna architettura della CPU, non ha tonnellate di ottimizzazioni di basso livello fatte ad esso, ecc. L'HotSpot GC di Java è a dir poco sorprendente, e le ottimizzazioni della VM tendono per essere meglio di ciò che un compilatore statico potrebbe fare.

D'altra parte, se hai davvero bisogno di prestazioni e sei disposto a mettere a punto le cose per ottenerle, C / C ++ / D offre molte più opportunità per questo. Non è possibile utilizzare l'assemblatore inline in Java. Non è possibile utilizzare i trucchi di punzonatura di tipo sporco per trattare i numeri in virgola mobile come matrici di bit. Non è possibile utilizzare schemi di gestione della memoria personalizzati che potrebbero essere più veloci del GC per il proprio caso d'uso specifico. Non è possibile allocare quasi nello stack in Java come in C / C ++ / D. In Java l'unico modo per ottenere qualcosa di più o meno equivalente a funzioni di ordine superiore è con interfacce e binding di runtime. In D e (penso, correggimi se sbaglio) C ++, puoi passare le funzioni ai template, permettendo che il binding avvenga in fase di compilazione senza perdita di flessibilità.

Un altro punto per "lentezza" di Java è il runtime a 64 bit.

Ho sentito alcune persone lamentarsi che Java è molto lento per loro su computer a 64 bit. A quanto pare, il runtime Java a 64 bit utilizza il server JVM che compila l'intero programma prima di iniziare.

QUI è la spiegazione del perché la VM a 64 bit si avvia più lentamente.

Ad esempio su Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

Le prestazioni di Java sono tuttavia molto soggettive, la percezione del perché Java è lenta è in gran parte per ragioni che altri hanno notato: la percezione della maggior parte delle persone di qualcosa è colorata dalla loro precedente esperienza con Java e Java non è sempre stato un linguaggio ottimizzato sotto la foresta. Allo stesso modo, Vanilla Eclipse non è esattamente un IDE veloce con cui lavorare e impallidisce in termini di reattività rispetto a un IDE come Visual Studio.

Detto questo, tuttavia, al di fuori dei problemi dell'interfaccia utente che Java ha all'avvio, è abbastanza veloce per la maggior parte delle applicazioni. Se esegui una ricerca, puoi trovare articoli che lo confrontano con altre lingue e la maggior parte dei risultati presentati lo inserisce nell'intervallo in cui sarà un problema solo quando hai a che fare con i principali set di dati.

Nel campo della bioinformatica viene usato un po 'perché è ben supportato e c'è già una base di installazione per, uno dei vantaggi che Java ha è che puoi fare uno sviluppo abbastanza rapido con esso che non puoi fare con C Se guardi i linguaggi usati per la bioinformatica (uso personalmente R, Python e Java regolarmente) noterai che nessuno di questi è esattamente il più veloce e non è insolito che i set di dati in bioinformatica finiscano negli anni 100 di gigabyte di informazioni. Alla fine della giornata, il tempo umano è ancora più prezioso e mentre le differenze di velocità sono evidenti, la dimensione dei set di dati tende ad essere abbastanza grande da funzionare comunque durante la notte.

Se fosse più facile scrivere un'interfaccia utente scattante in Java, è abbastanza come se la percezione della velocità cadesse dal radar poiché la maggior parte delle persone non spinge abbastanza le lingue che la velocità è davvero un problema su base giornaliera.

Per lanciare una moneta senza valore, trovo che le webapp Java abbiano generalmente lunghi tempi di avvio e di risposta, dove mi sembra che Python o Ruby avrebbero fatto di meglio.

Uso Eclipse per la maggior parte della mia programmazione e devo dire che Java è veloce come qualsiasi altra cosa, se non più veloce in esecuzione localmente e "autonomo".

Direi che Java è infinitamente lento, non solo lento, perché non riesce a risolvere problemi semplici che sono facili in linguaggi di alto livello.

Lasciami fare un semplice esempio. C'è una semplice ottimizzazione che si applica quando si mappa due volte un elenco, chiamato deforestazione: ecco la regola per esso scritta nella mia lingua Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

che dice: invece di mappare l'elenco x con f, quindi mapparlo di nuovo con g, richiedendo due attraversamenti di elenco e creando un elenco temporaneo di immondizia, basta mappare l'elenco con la composizione delle funzioni.

Si tratta di un'ottimizzazione di alto livello molto più significativa delle prestazioni di basso livello di Java JVM. Le specifiche che ho dato sopra non sono solo una sintassi piuttosto, questa è un'istruzione scritta dall'utente che dice al compilatore Felix come eseguire un'ottimizzazione.

Per favore, mostrami come fare questo genere di cose in Java. No? Quindi Java è lento. Molto lento. [Haskell può farlo automaticamente, credo].

E prima di dire "ma Java è un linguaggio OO, questo tipo di ottimizzazione non si applica" ... beh, questo è esattamente il mio punto. Java fa schifo ed essere OO è uno dei motivi principali.

L'ottimizzazione JIT non può mai avvicinarsi alla concorrenza con i tipi di ottimizzazioni che un compilatore decente può fare.