[Java] Uso della memoria, prestazioni, vs c++

[Johnn]

Volevo un po' di pareri riguardo alle prestazioni di Java soprattutto su come utilizza la memoria e in misura minore la cpu, in particolare in relazione ad uno stesso ipotetico programma scritto in c++, a parità di algoritmi e con una programmazione orientata in maniera massiccia all'ottimizzazione.
Per l'ambito, diciamo un programma per calcolo scientifico, assetato in maniera incredibile di ram, no calcoli in virgola mobile, no grafica, no I/O; il calcolo richiede molta potenza alla cpu, ma non ci sono vincoli di tempo (no real time, se finisce qualche min. prima o dopo nessun problema. Se finisce 2 giorni dopo sì )

Da una parte si sente sempre: "Java è pesante.", "Il programma X scritto in Java è lento", ecc. D'altra parte ho letto che:
Java è nato per sistemi embedded, dove l'hardware è limitato;
l'ottimizzazione del jvm è notevole e a volte può competere con la gestione della memoria lasciata al programmatore.
Lato cpu, Jit e ancora una volta la jvm si danno parecchio da fare. Sembra insomma che Java non sia ordini di grandezza più lento del c++. Ovviamente dipende da ciò che si vuole fare nel caso specifico. Leggendo un altro thread un grosso limite di Java è la casualità con cui interviene il garbage collector. Non si può usarlo quindi per programmi con stringenti vincoli di tempo. Ci sono altri problemi simili?

Inoltre vorrei sapere se:

in generale è sconsigliato usare Java per software dove anche l'ultimo bit è importante? Perché?

Un oggetto Java "spreca" della memoria oltre ai dati dichiarati dal programmatore? (Riguardo ciò, da una ricerca su internet fatta un po' di tempo fa, ho scoperto sorprendentemente che non si può sapere quanto occupa un oggetto se non con metodi poco ortodossi, tipo allocare 1000 oggetti e vedere quanto sale la ram occupata , o usando librerie esterne che non hanno garanzie di precisione).

Grazie!

[Johnn]

UP.

[Mixmar]

IMVHO:

E' vero che da una parte il linguaggio Java non consente l'ottimizzazione del codice che un programmatore C/C++ molto esperto sarebbe in grado di estrarre implementando lo stesso algoritmo in quel linguaggio su di una piattaforma che conosce molto bene, ma considera che:

1) Di questi programmatori ce n'è proprio pochi: la maggior parte degli sviluppatori preferisce la comodità di un ambiente managed e non ha la capacità / il tempo / la voglia di tenere presente tutti i problemi aggiuntivi che sviluppare software unmanaged ti da', problemi che scegliendo Java (ma, per correttezza, anche C#, Ruby, Python, etc) non si hanno. E bada bene che non si possono eliminare dalla programmazione C/C++ queste caratteristiche, perchè proprio la sua capacità di "basso livello" da una parte aumenta le possibili ottimizzazioni, dall'altra impedisce l'uso di automatismi da piattaforma managed, appunto.
2) Bisogna fare un bilancio che tenga conto del tempo di sviluppo impiegato: siamo sicuri che il tempo speso per ottimizzare quattro loop annidati risparmiando dieci cicli di CPU non sarebbe stato meglio speso ottimizzando il funzionamento del'algoritmo ad alto livello? (Nota che in C/C++ puoi fare entrambe le cose, ma evidentemente mentre fai l'una non puoi fare l'altra...).
3) Il codice ultraottimizzato è meno leggibile e meno manutebile di quello più astratto, perchè il primo si allontana dall'intuizione umana più del secondo.
4) Esistono ottime librerie già esistenti a cui delegare i calcoli più complessi e che possono beneficiare in maniera significativa anche delle più piccole ottimizzazioni: queste sono scritte in C/C++ e probabilmente resteranno sempre così, perchè potranno essere riutilizzate a piacere da programmi scritti in altri linguaggi (i driver per i dispositivi sono scritti in C, ma ne beneficia tutto il S.O. e tutti gli applicativi che ci girano sopra, siano essi scritti in Java, .NET, Python, Ruby, ...).
5) L'hardware "costa poco": un incremento prestazionale del 5% si può ottenere aumentando i Mhz del processore con una spesa che magari è inferiore a quella del tempo di un team per ottimizzare in maniera estrema del codice.

Al di là di queste considerazioni "personali", posso dire di aver avuto l'impressione che in ambito di ricerca accademica capiti spesso che venga usato il linguaggio Java anche per simulazioni e calcoli dove le prestazioni sono importanti, senza particolari lamentele.

[tomminno]

Il vantaggio dei linguaggi managed, risiede nella libreria che mettono immediatamente a disposizione dello sviluppatore, non tanto nella mancanza della gestione diretta della memoria (in quanto nei linguaggi managed devi gestirti a mano la "deallocazione" di oggetti che usano risorse non gestite es connessioni db, tcp, file...).
Prova ad aprire connessioni magari al database centrale dell'azienda e ad aspettare che sia il GC a chiuderle, il server comincia a segnalare che ci sono troppe connessioni nel giro di pochi minuti, fermando il lavoro di tutta l'azienda.
Il fatto che siano lenti (e lo sono anche parecchio in confronto al C++, al lavoro è una situazione che vedo praticamente tutti i giorni) non interessa quanto l'uniformità della piattaforma di sviluppo.

E l'hardware non costa affatto poco. Un computer assemblato a mano costa poco, prova a sentire quanto costa un server rack e magari visto che stiamo parlando di elevati volumi di traffico magari 2 con un bilanciatore e mettici pure un NAS dietro per tutti i dati. Ecco questo è il livello minimo di hardware, in più conta le licenze...

[incipit1970]

Java non mi sembra particolarmente lento. Ha senz'altro alcuni problemi di performance (il GC, il fatto che i programmi vengono impacchettati in archivi zip, richiedendo una fase di scompattamento prima dell'esecuzione, etc.), ma niente di terribile.

Tutti i programmi impongono un trade-off tra flessibilità e potenza: Java è stato pensato per essere meno complicato di C++, ed in cambio paga un prezzo in performance. Lo stesso si dica di qualsiasi altro programma che "semplifica" la programmazione (in media, maggiore è l'astrazione dal linguaggio macchina, maggiore è la penalità in termini di performance). Anche C++ è meno performante di C...

L'importante dunque è scegliere il linguaggio giusto per ogni compito: se devi ottimizzare al massimo, meglio se usi C++ o persino C (di rado in un programma di calcolo hai bisogno delle estensioni object oriented di C++, hanno un costo in performance pure quelle). Se invece qualche perdita di velocità è accettabile, pur di avere una programmazione più semplice e meno complicata, ben venga Java o C#, o Python...

E' vero che un server enterprise è costoso, ma costa di più mantenere un codice più complesso: il costo di assumere 4-5 programmatori per un anno supera di gran lunga il costo di un server di prima categoria. Inoltre, Java è ricco di codice evoluto open source che altrimenti bisognerebbe sviluppare in-house o acquisire in costose librerie... infatti, Java è molto comune in ambiti aziendali per questi motivi.

[Johnn]

Volevo proprio capire quanto sia possibile avvantaggiarsi degli aspetti positivi di un linguaggio come Java da voi menzionati nel caso del tipo di software del mio primo thread.

Perché ancora non ho ben compreso quali sono le problematiche che portano a dire a tomminno: "Il fatto che siano lenti (e lo sono anche parecchio in confronto al C++" e nello stesso tempo a incipit1970:
"Java non mi sembra particolarmente lento. Ha senz'altro alcuni problemi di performance ..., ma niente di terribile."

Ho capito che il GC non si sa quando va in esecuzione (anche se lo si può chiamare forzatamente).
Ma per il resto, soprattutto sull'uso della memoria?

Grazie ancora.

[variabilepippo]

Prova ad aprire connessioni magari al database centrale dell'azienda e ad aspettare che sia il GC a chiuderle, il server comincia a segnalare che ci sono troppe connessioni nel giro di pochi minuti, fermando il lavoro di tutta l'azienda.

Ma la corretta gestione delle connessioni (aperture/chiusure/transazioni/...) ad un database è comunque compito del programmatore, non del GC, ovvero di una tecnica di gestione della memoria che al massimo può sollevare lo sviluppatore da problemi di allocazione/deallocazione della memoria, dangling pointers, memory leaks, etc.

[Mixmar]

Originariamente inviato da tomminno

Il vantaggio dei linguaggi managed, risiede nella libreria che mettono immediatamente a disposizione dello sviluppatore, non tanto nella mancanza della gestione diretta della memoria (in quanto nei linguaggi managed devi gestirti a mano la "deallocazione" di oggetti che usano risorse non gestite es connessioni db, tcp, file...).

Sì, ma come osserva variabilepippo più sotto, questo vale anche nei linguaggi unmanaged: la differenza che volevo sottolineare io era che un linguaggio managed (o meglio, come correttamente osservi, la sua piattaforma sottostante) risolve automaticamente un problema in più di quello che fanno i linguaggi unmanaged.

Originariamente inviato da tomminno

Il fatto che siano lenti (e lo sono anche parecchio in confronto al C++, al lavoro è una situazione che vedo praticamente tutti i giorni) non interessa quanto l'uniformità della piattaforma di sviluppo.

Mmmm... qui parliamo di impressioni personali: il fatto è che è difficile fare paragoni oggettivi, perchè raramente usiamo linguaggi managed e unmanaged per fare la stessa cosa: gli ambiti di sviluppo si separano naturalmente all'atto della scelta dei linguaggi. A me per esempio non viene in mente un caso di sviluppo in ambito enterprise "convenzionale" (DB + Web app, per intenderci) in cui la velocità del compilato sia determinante, anche perchè solitamente i "colli di bottiglia" sono i database e/o le connessioni di rete, cose sulle quali il programma contenente la logica applicativa può avere pochissimo effetto.

Originariamente inviato da tomminno

E l'hardware non costa affatto poco. Un computer assemblato a mano costa poco, prova a sentire quanto costa un server rack e magari visto che stiamo parlando di elevati volumi di traffico magari 2 con un bilanciatore e mettici pure un NAS dietro per tutti i dati. Ecco questo è il livello minimo di hardware, in più conta le licenze...

Il mio era un discorso di tipo differenziale: avendo una disposizione due versioni dello stesso applicativo, di cui una scritta con un linguaggio managed ed una con un linguaggio unmanaged, la differenza di pura velocità di esecuzione (perchè di questa parliamo) giustificherebbe la differenza di prezzo?

Rinunceresti alla SAN con i canali in fibra? No, perchè non è per la velocità di esecuzione che l'hai presa verosimilmente.
Rinunceresti agli switch di rete ridondati? No, perchè non è per la velocità di esecuzione che ne hai ordinati due.
Forse, diciamo, potresti evitare di comprare uno dei quattro server che stanno dietro al tuo load balancer (al quale non puoi rinunciare, per i motivi di cui sopra): il risparmio si ridurrebbe perciò ad un paio di migliaia di euro.

Però in cambio dovresti rinunciare a tutti i benefici di una piattaforma managed...

Intendiamoci, io non sono un grande esperto di questo genere di questioni, riporto solo le mie impressioni personali, che derivano da un po' di esperienza e da un po' di sentito dire, però non mi sentirei di dire, a tutt'oggi, che sia meglio intraprendere uno sviluppo su di un sistema unmanaged piuttosto che uno managed, nella maggioranza dei casi.

Tornando poi al caso esposto da Johnn, forse farebbe premio la maggiore "riusabilità" del codice managed (specie se scritto secondo i criteri dell'OO, ma se si parla di Java, C#, Ruby, Python, ...) rispetto alle maggiori performance di quello funzionale, perchè ritengo (ma è solo una sensazione) che la perdita di performance, anche se ci fosse, sarebbe comunque una percentuale poco significativa dell'esecuzione del totale. E siccome non si tratta di compiti rt, ne deduco che, per esempio, aspettare 31 giorni per un risultato anzichè 30 non farebbe molta differenza.

Originariamente inviato da variabilepippo

Ma la corretta gestione delle connessioni (aperture/chiusure/transazioni/...) ad un database è comunque compito del programmatore, non del GC, ovvero di una tecnica di gestione della memoria che al massimo può sollevare lo sviluppatore da problemi di allocazione/deallocazione della memoria, dangling pointers, memory leaks, etc.

[tomminno]

Originariamente inviato da variabilepippo

Ma la corretta gestione delle connessioni (aperture/chiusure/transazioni/...) ad un database è comunque compito del programmatore, non del GC, ovvero di una tecnica di gestione della memoria che al massimo può sollevare lo sviluppatore da problemi di allocazione/deallocazione della memoria, dangling pointers, memory leaks, etc.

Scusa che differenza c'è tra chiamare correttamente una delete e chiamare correttamente un metodo Dispose?

Poi puntualmente trovi metodi Dispose chiamati male, perchè tanto c'è il GC, nessuno ha mai imparato a gestire la memoria e quindi la deallocazione corretta delle risorse, nessuno si prende la briga di studiare lo using...

[tomminno]

Originariamente inviato da incipit1970

Java non mi sembra particolarmente lento. Ha senz'altro alcuni problemi di performance (il GC, il fatto che i programmi vengono impacchettati in archivi zip, richiedendo una fase di scompattamento prima dell'esecuzione, etc.), ma niente di terribile.

Le interfacce grafiche in Java sembrano lentissime anche su dei Core2Duo ben carrozzati.
Sia all'avvio sia durante l'esecuzione, ho come esempio NetBeans che ci mette 40 secondi ad avviarsi e spesso si ferma a pensare quando devi aprire un menu o altro.
Ma la mia esperienza con Java è disastrosa su tutti i computer che ho potuto provare, contrariamente a quello che riportano altri.
Probabilmente quello che per me è inaccettabile come prestazioni per altri risulta adeguato.

Tutti i programmi impongono un trade-off tra flessibilità e potenza: Java è stato pensato per essere meno complicato di C++, ed in cambio paga un prezzo in performance. Lo stesso si dica di qualsiasi altro programma che "semplifica" la programmazione (in media, maggiore è l'astrazione dal linguaggio macchina, maggiore è la penalità in termini di performance). Anche C++ è meno performante di C...

La programmazione ti è semplificata dalla libreria standard del linguaggio in primis e poi dagli strumenti che ruotano attorno.
Ad esempio se devi fare un'applicazione enterprise, non c'è C# che tenga, Java ha strumenti molto migliori ed è quindi più produttivo.
Al contrario per lo sviluppo di un applicativo desktop, il vantaggio del linguaggio si fa sentire.

L'importante dunque è scegliere il linguaggio giusto per ogni compito: se devi ottimizzare al massimo, meglio se usi C++ o persino C (di rado in un programma di calcolo hai bisogno delle estensioni object oriented di C++, hanno un costo in performance pure quelle). Se invece qualche perdita di velocità è accettabile, pur di avere una programmazione più semplice e meno complicata, ben venga Java o C#, o Python...

Se parti da una libreria che è pari come funzionalità a quella integrata nei linguaggi managed non ho trovato particolari svantaggi nello sviluppo, ma anche in applicativi semplici come di log parser i vantaggi prestazionali sono mediamente 1:8, per lo meno per la mia esperienza.
Certo se l'ottica è di incrementare il numero di server ogni anno al posto del numero di sviluppatori, chi se ne frega.

[tomminno]

Originariamente inviato da Mixmar

Sì, ma come osserva variabilepippo più sotto, questo vale anche nei linguaggi unmanaged: la differenza che volevo sottolineare io era che un linguaggio managed (o meglio, come correttamente osservi, la sua piattaforma sottostante) risolve automaticamente un problema in più di quello che fanno i linguaggi unmanaged.

Veramente anche nei linguaggi managed devi deallocarti correttamente le risorse unmanaged, da una parte gestisci manualmente la memoria, dall'altra gestisci manualmente tutte le altre risorse, non ci vedo una gran differenza.

Per la mia esperienza trovo sempre colleghi che non hanno mai studiato il C/C++ che non usano correttamente la deallocazione delle risorse anche in linguaggi managed e questo a volte causa più danni di un memory leak in un singolo applicativo, tipo saturazione delle connessioni al db.

Mmmm... qui parliamo di impressioni personali: il fatto è che è difficile fare paragoni oggettivi, perchè raramente usiamo linguaggi managed e unmanaged per fare la stessa cosa: gli ambiti di sviluppo si separano naturalmente all'atto della scelta dei linguaggi.

Ho avuto modo di fare esattamente gli stessi applicativi in più linguaggi e con un codice che è praticamente identico (tra l'altro assolutamente if-less), salvo le dovute differenze di linguaggio, la differenza prestazionale in questi casi era 1:8 e il bello è che essendo stato lo sviluppo C++ il porting di quello C# non mi ha portato via più di un paio d'ore, con il vantaggio che ora i parser riescono ad elaborare nelle 24 ore e a stare al passo con le tonnellate di log giornaliere.

A me per esempio non viene in mente un caso di sviluppo in ambito enterprise "convenzionale" (DB + Web app, per intenderci) in cui la velocità del compilato sia determinante, anche perchè solitamente i "colli di bottiglia" sono i database e/o le connessioni di rete, cose sulle quali il programma contenente la logica applicativa può avere pochissimo effetto.

Infatti il C++ ormai è in disuso nelle aziende, relegato solo ad ambienti embedded, encoding audio/video; perchè ci sono aziende come Microsoft e Sun che hanno creato ambienti di sviluppo migliori.
A nessuno interessa la velocità di esecuzione.

Il mio era un discorso di tipo differenziale: avendo una disposizione due versioni dello stesso applicativo, di cui una scritta con un linguaggio managed ed una con un linguaggio unmanaged, la differenza di pura velocità di esecuzione (perchè di questa parliamo) giustificherebbe la differenza di prezzo?

Sei sicuro che costerebbe di più?

Rinunceresti alla SAN con i canali in fibra? No, perchè non è per la velocità di esecuzione che l'hai presa verosimilmente.
Rinunceresti agli switch di rete ridondati? No, perchè non è per la velocità di esecuzione che ne hai ordinati due.
Forse, diciamo, potresti evitare di comprare uno dei quattro server che stanno dietro al tuo load balancer (al quale non puoi rinunciare, per i motivi di cui sopra): il risparmio si ridurrebbe perciò ad un paio di migliaia di euro.

Magari triplica la cifra che hai menzionato.
Comunque ormai i linguaggi managed sono lo standard aziendale, perchè sono stati creati strumenti intorno che li rendono intrinsecamente migliori.

Però in cambio dovresti rinunciare a tutti i benefici di una piattaforma managed...

Che sono l'ambiente di sviluppo e gli strumenti immediatamente disponibili allo sviluppatore.

Intendiamoci, io non sono un grande esperto di questo genere di questioni, riporto solo le mie impressioni personali, che derivano da un po' di esperienza e da un po' di sentito dire, però non mi sentirei di dire, a tutt'oggi, che sia meglio intraprendere uno sviluppo su di un sistema unmanaged piuttosto che uno managed, nella maggioranza dei casi.

Anche perchè non hai alternative, le aziende oggi lavorano in Java o .NET.

Solo che a volte rimani scottato come con .NET 1.1 il cui ambiente di sviluppo non è più supportato in Vista e gli applicativi sono non importabili nei nuovi ambienti.

Tornando poi al caso esposto da Johnn, forse farebbe premio la maggiore "riusabilità" del codice managed (specie se scritto secondo i criteri dell'OO, ma se si parla di Java, C#, Ruby, Python, ...) rispetto alle maggiori performance di quello funzionale, perchè ritengo (ma è solo una sensazione) che la perdita di performance, anche se ci fosse, sarebbe comunque una percentuale poco significativa dell'esecuzione del totale. E siccome non si tratta di compiti rt, ne deduco che, per esempio, aspettare 31 giorni per un risultato anzichè 30 non farebbe molta differenza.

Credo che per funzionale tu intenda procedurale ovvero C (e non C++), altrimenti pensa che C# ha introdotto elementi di programmazione funzionale.

[marco.r]

Originariamente inviato da tomminno

Prova ad aprire connessioni magari al database centrale dell'azienda e ad aspettare che sia il GC a chiuderle, il server comincia a segnalare che ci sono troppe connessioni nel giro di pochi minuti, fermando il lavoro di tutta l'azienda.

Il garbage collector serve per la gestione della memoria, non delle risorse. Usarlo anche per quest'ultimo e' di solito un errore indotto da cattive librerie di sistema o da un linguaggio mal progettato. Molti linguaggi di alto livello supportano un uso corretto delle risorse (Ruby, Python, CL etc.)

[marco.r]

Originariamente inviato da tomminno

Scusa che differenza c'è tra chiamare correttamente una delete e chiamare correttamente un metodo Dispose?

Poi puntualmente trovi metodi Dispose chiamati male, perchè tanto c'è il GC, nessuno ha mai imparato a gestire la memoria e quindi la deallocazione corretta delle risorse, nessuno si prende la briga di studiare lo using...

Doversi occupare "solo" delle risorse e' comunque un vantaggio, perche' piu' localizzate e facili da gestire, in quanto e' piu' chiaro chi sia il "proprietario". In teoria dovrebbero essere necessari ben pochi Dispose.

[marco.r]

Originariamente inviato da tomminno

Le interfacce grafiche in Java sembrano lentissime anche su dei Core2Duo ben carrozzati.
Sia all'avvio sia durante l'esecuzione, ho come esempio NetBeans che ci mette 40 secondi ad avviarsi e spesso si ferma a pensare quando devi aprire un menu o altro.
Ma la mia esperienza con Java è disastrosa su tutti i computer che ho potuto provare, contrariamente a quello che riportano altri.
Probabilmente quello che per me è inaccettabile come prestazioni per altri risulta adeguato.

Sono dell'opinione che piu' che che al linguaggio in se' la lentezza sia dovuta piu' a come e' architettata la libreria standard, con cataste di metodi ed oggetti. E' anche evidente che quando e' stata ideata le performance non erano tra i requisiti principali e la cosa si nota. Basta confrontare le classi di I/O di Java e C++ per notare la differenza. Questa tendenza tra l'altro mi sembra si sia diffusa anche agli utilizzatori, con i deleteri effetti del caso.

[71104]

Originariamente inviato da Mixmar

perchè proprio la sua capacità di "basso livello" da una parte aumenta le possibili ottimizzazioni, dall'altra impedisce l'uso di automatismi da piattaforma managed, appunto.

chi l'ha detto, i garbage collectors esistono anche per C++.

queste sono scritte in C/C++ e probabilmente resteranno sempre così, perchè potranno essere riutilizzate a piacere da programmi scritti in altri linguaggi

come mai adesso una libreria può essere utilizzata da programmi scritti in altri linguaggi solo se scritta in C o C++?

(i driver per i dispositivi sono scritti in C, ma ne beneficia tutto il S.O. e tutti gli applicativi che ci girano sopra, siano essi scritti in Java, .NET, Python, Ruby, ...).

i drivers non sono librerie, spero sia chiaro...

[71104]

Originariamente inviato da tomminno

Le interfacce grafiche in Java sembrano lentissime anche su dei Core2Duo ben carrozzati.
Sia all'avvio sia durante l'esecuzione, ho come esempio NetBeans che ci mette 40 secondi ad avviarsi e spesso si ferma a pensare quando devi aprire un menu o altro.
Ma la mia esperienza con Java è disastrosa su tutti i computer che ho potuto provare, contrariamente a quello che riportano altri.
Probabilmente quello che per me è inaccettabile come prestazioni per altri risulta adeguato.

Originariamente inviato da marco.r

Sono dell'opinione che piu' che che al linguaggio in se' la lentezza sia dovuta piu' a come e' architettata la libreria standard, con cataste di metodi ed oggetti. E' anche evidente che quando e' stata ideata le performance non erano tra i requisiti principali e la cosa si nota. Basta confrontare le classi di I/O di Java e C++ per notare la differenza. Questa tendenza tra l'altro mi sembra si sia diffusa anche agli utilizzatori, con i deleteri effetti del caso.

bla bla bla

ovviamente inutile dire che sono l'unico fortunello a cui i menu di NetBeans si aprono al click e che di certo non ho un Core2Duo ben carrozzato

edit - sapete indicarmi uno di quei programmi per registrare un video di ciò che accade sullo schermo? vorrei prendere un video dell'apertura di un menu di uno di quei programmoni Java belli grassi e grossi, tipo Eclipse e NetBeans, così poi ve lo faccio vedere

[tomminno]

Originariamente inviato da marco.r

Il garbage collector serve per la gestione della memoria, non delle risorse. Usarlo anche per quest'ultimo e' di solito un errore indotto da cattive librerie di sistema o da un linguaggio mal progettato. Molti linguaggi di alto livello supportano un uso corretto delle risorse (Ruby, Python, CL etc.)

Il GC chiude le risorse quando esegue, ma te prova a fare delle sqlconnection e a non chiamare manualmente il dispose in maniera corretta, replica questa circostanza per migliaia di applicativi che girano intorno ad un db aziendale e vedrai l'uso corretto delle risorse che fine fa.

[tomminno]

Originariamente inviato da marco.r

Doversi occupare "solo" delle risorse e' comunque un vantaggio, perche' piu' localizzate e facili da gestire, in quanto e' piu' chiaro chi sia il "proprietario". In teoria dovrebbero essere necessari ben pochi Dispose.

In C# forse nessuno se è il caso di usare lo using. Però una volta che qualcuno ti passa un riferimento potresti fare il Dispose nel momento sbagliato esattamente come la delete

[khelidan1980]

Originariamente inviato da 71104

bla bla bla

ovviamente inutile dire che sono l'unico fortunello a cui i menu di NetBeans si aprono al click e che di certo non ho un Core2Duo ben carrozzato

edit - sapete indicarmi uno di quei programmi per registrare un video di ciò che accade sullo schermo? vorrei prendere un video dell'apertura di un menu di uno di quei programmoni Java belli grassi e grossi, tipo Eclipse e NetBeans, così poi ve lo faccio vedere

Non renderebbe l'idea,in quei video la reattività del sistema sembra di un ordine di grandezza inferiore!

Originariamente inviato da tomminno

Le interfacce grafiche in Java sembrano lentissime anche su dei Core2Duo ben carrozzati.
Sia all'avvio sia durante l'esecuzione, ho come esempio NetBeans che ci mette 40 secondi ad avviarsi e spesso si ferma a pensare quando devi aprire un menu o altro.
Ma la mia esperienza con Java è disastrosa su tutti i computer che ho potuto provare, contrariamente a quello che riportano altri.
Probabilmente quello che per me è inaccettabile come prestazioni per altri risulta adeguato.

Sinceramente Eclipse non mi sembra poi così lento

[tomminno]

Originariamente inviato da 71104

edit - sapete indicarmi uno di quei programmi per registrare un video di ciò che accade sullo schermo? vorrei prendere un video dell'apertura di un menu di uno di quei programmoni Java belli grassi e grossi, tipo Eclipse e NetBeans, così poi ve lo faccio vedere

Cerchi qualcosa tipo questo?
http://www.microsoft.com/windows/win...screencap.aspx