Newsgroup: it.comp.java
Titolo: Domanda (provocatoria)....

Ciao a tutti,
secondo voi, allo stadio attuale di sviluppo della piattaforma Java, qual'è 
la più grande lacuna del linguaggio, sotto qualunque punto di vista 
(pratico, architetturale,etc) ?
Saluti,
    Scorpio. 

 (pratico, architetturale,etc) ?
sovraingegnerizzazione.


Io me la sono presa male quando hanno introdotto l'autoboxing, cioè la
conversione "silente" fra tipi primitivi e oggetti; ad esempi fra int
e Integer, ecc. Rischia di farti introdurre di quei bachi pazzeschi e
invisibili che fa accapponare la pelle al programma-cose di una certa
esperienza...
Per il resto mi piace quasi tutto. Ah, ecco, i Generics potevano
essere fatti meglio, per come sono ora alle volte sono solo una
perdita di tempo.
www.megadix.it

Bellissima domanda :-)
secondo me il grosso problema è la quantità enorme di framework,
che nascondendo un sacco di roba fanno in modo che non si capisca bene
quello che facciano.
inoltre una cosa che non mi piace è che tante cose in j2ee non sono
universali,
ma dipendenti dall' application server, con file specifici e
documentazione specifica.
Gradirei avere solo un file WEB.XML e non
WEB.XML + ORION-WEB.XML, ad esempio!

 (pratico, architetturale,etc) ?
del linguaggio in se... non saprei... a me sta bene.
riguardo alle librerie c'e' una gigantesca lacuna sul fronte multimediale:
audio, video, ecc.
il java media framework e' morto, sembra pero' che se ne stiano rendendo
conto, molto lentamente come al solito (in sun hanno un'inerzia
spaventosa)
http://weblogs.java.net/blog/chet/archive/2007/05/media_frenzy.html

Scorpio ha pensato forte :

Personalmente direi, per quanto mi piaccia Java: le performance! Non 
sono microsoft-oriented ma bisogna riconoscere che un programma .NET 
avrà il CLR ma a vista mi sembra essere un programma VB 6.0 
tradizionale..
quando lancio un programma java mi sembra sempre di aver fatto doppio 
click su elefante.exe.
la cosa va un po' meglio con il JRE di BEA (jrockit) però secondo me 
siamo lontani...
Probabilmente si tratta di una semplice sensazione personale che magari 
denoterà anche la mia ignoranza a riguardo: se così fosse sarei felice 
di capire dove sbaglio nell'utilizzare Java e avere performance 
decenti.
ciao ciao
andrea

 andrea
Per la mia esperienza personale, le performance della JVM Sun sono
scadenti *solo* per quello che riguarda l'avvio e il consumo di memoria.
Ho fatto girare piccoli programmi AWT sulla J9 di IBM (che però è una JVM
12ME CDC, non J2SE) e sono rimasto colpito di quanto sia veloce l'avvio,
al punto di iniziare a ragionare se fosse possibile portare su quella
piattaforma gli applicativi.
Per le performance complessive di un programma operativo, devo dire che
Java 5.0 e 6.0 sono molto soddisfacenti, al pari di un applicativo nativo.
Al contrario, programmi .NET che sono costretto ad usare (fatti da altri,
software house giganti) sono talmente dei mattoni che devo controllare
giorni prima se ho una mezz'ora di tempo per fare due semplici operazioni,
e segnarmi l'appuntamento in agenda.
Ciao
gl


Cito ad esempio PSPad:
- grande editor;
- scritto in .NET;
- lento in startup, esattamente come Java!!!
A questo punto sono tornato al buon JEdit, che una volta partito è
come non averlo...per non parlare si SQuirrel, NetBeans 5.5 (proprio
lui!) e altri :)


Si anche io conosco software di questo tipo ma suppongo siano fatti 
sviluppati male.
Io ho notato differenze tra java / .net anche in semplici HelloWorld.
In .NET ho un applicativo accettabile
In Java ho l'effetto elefante.exe :)
Non sono un grande esperto di .NET ma ricordo al momento della 
presentazione della tecnologia si parlava della funzione di JIT per cui 
il codice veniva compilato nativamente solo alla prima richiesta
e dalla seconda volta in poi, l'applicativo era quasi "nativo".
Come idea (a patto che non si trattasse di chiacchiere commerciali e 
che io abbia capito correttamente :)) mi sembra molto valida. Java 
manca di questo?
ciao
andrea

 click su elefante.exe.
Sullo startup è ovvio che non c'è paragone. Da una parte hai una VM e
dall'altra parte no.
Le performance è giusto confrontarle durante l'operatività,
specialmente per le applicazioni web dove magari la VM la tiri su una
volta l'anno. La differenza in quei casi non è così abissale, anzi.


Risposta provocatoria :)
Secondo me il problema più grosso di Java è la sua eccessiva 
"trasparenza". E' stato fatto davvero troppo bene e i suoi dettagli e 
meccanismi interni sono talmente tanto noti che, purtroppo, troppa gente 
ogni tanto vuole cimentarsi a introdurre modifiche.
pole che è preoccupato da cosa uscirà fuori col JDK 7...
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.html

 varie...
Non contestualizzato questo vuole dire poco. Mi spiego: se stai
scrivendo codice particolarmente computazionalmente intensivo, C è
comunque in testa.
La gestione *manuale* della memoria in questo caso è un vantaggio: è più
prevedibile [ tipicamente se scrivi codice per esempio numerico anche le
malloc vanno piazzate saggiamente ]. 
Allo stesso modo la visione a bassissimo livello. 
Esattamente come ulteriori miglioramenti si hanno utilizzando
eventualmente il codice macchina (per esempio ce ne si può accorgere
facendo compilare gmp con l'ordine di *non* usare le ottimizzazioni in
ASM).
Il punto che è solo una piccola parte di software quello che ha i
problemi di cui sopra. Se fai una query a DB il grosso del tempo va
nell'elaborazione da parte del db, non dal fatto che stai usando Java,
C++, Python o PHP.
Allo stesso modo un'applicazione di rete giova di più da una saggia
politica di gestione delle risorse (oltre che a non cercare di fare i
furbi con il kernel -- come dimostra per esempio varnish vs. squid --
http://varnish.projects.linpro.no/wiki/ArchitectNotes
 -- ) che dal
linguaggio in se. 
Quindi *non* sono d'accordo con la tua affermazione, ma sulla sua
contestualizzazione si.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 (pratico, architetturale,etc) ?
Premessa: a me Java complessivamente *non* piace. Il motivo č che č
*troppo* ingessato. Una volta che si decide di usarlo credo si essere
d'accordo con rootkit: la sovraingegnerizzazione (e la tendenza a
sovraingegnerizzare) č il problema principale.


Innanzitutto grazie a tutti quelli che hanno risposto, sono contento di aver 
sentito tanti pareri. Beh, a questo punto dico la mia, che, ovviamente, è un 
'opinione personale che conta quel che conta...
Secondo me oggi come oggi Java lato server è difficilmente superabile: a 
parte le effettive difficoltà nel deploy dell'applicazione (per "adattamenti 
e particolarità" dei singoli application server), il codice è effettivamente 
ultra-portabile senza mal di testa. Inoltre le applicazioni Java scalano 
davvero bene: a fronte di richieste importanti in numero e in frequenza di 
arrivo, gli appserver rispondono bene, senza *sedersi*, con tempi mediamente 
accettabili.
Invece, le magagne maggiori le trovo lato desktop, dove vi è, secondo me, 
una difficoltà del tutto "pratica": non è facile far lavorare in sinergia un 
applicativo Java con altri programmi come Outlook o Word (anche se con 1.6 
le cose stanno cambiando). Per realizzare questo tipo di integrazione, di 
solito, devo scrivermi piccoli tools che usano le api native WIN o ricorrere 
a JNI. Peraltro, per un linguaggio che deve essere indipendente dalla 
piattaforma, la scarsa - o nulla - integrazione con il sistema operativo 
sottostante deve essere un must... ma su applicativi non server side, questa 
integrazione serve eccome.
Vi racconto l'ultimo problema, sulla carta una scempiaggine: stampare PDF su 
stampanti che non supportano il formato PDF nativamente. Un incubo: per 
risolverlo, in modo che fosse "quick and dirty" sono stato costretto ad una 
chiamata esterna a GhostView. Beh, con MFC di Microsoft questo non sarebbe 
stato, credo, necessario. Con .NET neppure.
Altro "problema" (ma è davvero tale ? In fondo, è indice di vitalità della 
comunità di sviluppatori...) è il proliferare di framework, come faceva 
notare stefanomnn: sia di SUN che non-SUN, sono semplicemente troppi. 
Quante API di persistenza circolano, per esempio ? Quante implementazioni 
delle COMM Api ? Mentre, su altri fronti, c'è nebbia. Ad oggi, non c'è un 
JRE che giri su PDA in modo decente. E quelli che ci sono, sono rimasti 
all'età della pietra.....
Saluti a tutti... sperando che la discussione continui :-))
Scorpio.

 rimasti all'età della pietra.....
L'ambiente WebSphere Micro Envinroment di IBM (J9) è ottimo.
Me ne sono invaghito al punto da volerlo usare anche per applicativi
desktop :)
ciao
gl

 PostScript o PDF.
Sono curioso, davvero, di sapere come hai fatto. Se uso il PrintService 
divento matto.... 

 questo?
Credo che la definizione di JIT sia stata introdotta da Java molti anni fa...
http://it.wikipedia.org/wiki/Linguaggio_di_programmazione_Java
ciao
gl


sarei curioso di capire cosa rende "diverso" .NET. Non penso si tratti 
di suggestione. Ovviamente parlo di programmi GUI. Forse sarà l'utlizzo 
nativo o migliore delle librerie grafiche / widget ecc. Non so :).
Comunque sapevo del JIT anche di Java ma l'ho visto particolarmente 
pubblicizzato per .NET e pensavo fosse qualcosa di concettualmente 
differente (e magari l'origine della differenza nelle performance che 
noto tra .NET e Java).
ciao ciao
Andrea

 noto tra .NET e Java).
Il JIT di .NET è ciò che rende .NET inutilizzabile.
Sinceramente.
Uso un programma .NET fatto da una software house italiana di grandi
dimensioni per collegarmi al loro sistema e operare su stampe di contratti.
Stampe di contratti, non il dominio dell'universo.
Se devo fare una qualunque operazione, non posso semplicemente farlo
quando mi serve, devo pianificare il giorno prima di tenere mezz'ora
libera per stampare due pagine.
Eppure eseguo l'applicativo su una macchina di pari generazione di quella
su cui il mio applicativo in Java (scritto da me non una software house di
rilevanza nazionale) si carica in 5 secondi e ha prestazioni paragonabili
a applicativi nativi (pari al file manager di sistema).
Sei sicuro che le applicazioni a cui ti riferisci girino in .NET?
Ho i miei dubbi.
ciao
gl

 Ho i miei dubbi.
Penso di aver intuito a quale applicativo fai riferimento e, se ho 
indovinato, vale il discorso di "problemi progettuali". Il mio 
helloworld di esempio non era per portare l'attenzione su programmi 
stupidi:
un programma complesso può avere problemi di performance per tante 
ragioni tra cui le scelte progettuali, db, ecc. ecc.
ti parlo dell'helloworld per avere un qualcosa di talmente semplice da 
non poter avere il dubbio che forse hai sbagliato algoritmo.
Comunque questa è la mia esperienza sincera e spassionata. Non sono 
microsoft oriented, per la cronaca al momento l'80% del mio sviluppo è 
tutto su tecnologie linux / opensource / java.
Però non devi prendertela se faccio queste osservazioni: se le faccio 
qui è perchè mi va di discutere con altri tra cui te e capire, mica per 
denigrarti Java :).
ciao a presto
andrea

 discutere con altri tra cui te e capire, mica per denigrarti Java :).
I criteri per cui abbiamo scelto Java e non un altro linguaggio /
piattaforma non sono le opinioni degli altri :)
Mi basta sapere che almeno Sun, IBM, HP, BEA producono implementazioni di
Java per stare sicuro che la piattaforma ha un lungo futuro.
Il rilascio open source dei sorgenti di java è un plus, ma non è mai stato
determinante per la scelta.
E' determinante l'elemento cross platform e la riusabilità di librerie e
competenze in ambienti estremamente eterogenei.
Io ho solo l'impressione che, in generale, chi si lamenta di Java riesce
solo ad argomentare che è lento, ma non è così.
Java è una piattaforma robusta, stabile, scalabile e performante, con un
ecosistema infinito di librerie e conoscenze facilmente reperibili in rete.
Tra le cose reperibili in rete, molti benchmark di comparazione tra Java e
C, ovvero tra un linguaggio che molti considerano (molto) lento e uno che
molti considerano (molto) veloce.
Dipende dalla fonte dei test, alcuni test hanno anche dato Java vincente
(specialmente contro C++ con uso intensivo di classi ed ereditarietà)
Faccio molta fatica a trovare benchmark di Java contro .NET e anche di
.NET contro C.
Forse sono proprio su scale di valori differenti. :)
ciao
gl

 gl

 writes:
S> Vi racconto l'ultimo problema, sulla carta una scempiaggine:
S> stampare PDF su stampanti che non supportano il formato PDF
S> nativamente.
"Cazzata" del S.O. se non e` in grado di presentarti una stampante che
risolva il tuo problema.
Ho  appena stampato  un  pdf dandolo  in  pasto ad  una stampante  che
stupida ma così  stupida non ne trovi (Hp720 C),  forse quella ad aghi
del vic20  era così  torda. L'ho  fatto come avrei  fatto per  un file
ascii o un postscript. 
Da un qualsiasi linguaggio avrei mandato il file alla coda, il S.O. si
sarebbe occupato del resto.
Nei linguaggi fatti da chi ha fatto la cavolata (e sa di averla fatta)
ci hano messo  una pezza. Ma "se funziona  non devi ripararlo", quindi
altrove la cosa non serve.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a 
fn...@rat.vg

 andrea
Per quanto riguarda il lato client, considera cosa si riesce a fare con
una JVM ben ottimizzata come quelle J2ME dei cellulari.
Poche risorse e applicativi funzionanti (anche se MIDP/CLDC)
Dovresti provare la IBM WebSphere (J2ME CDC) per Linux o Windows.
Non è una J2SE, ma con quella decisamente il tempo di avvio è di circa ~0
sec.
Tanto da poterci fare un pensierino su, ma solo un pensierino però :)
ciao!
gl

 e interesse...
Sinceramente penso che tu abbia ragione su molte cose e che Java sia 
valido ma, al contempo, che tu sia troppo di parte e molte volte 
anzicchè rispondere alle mie domande evadi facendo paragoni o consigli 
che non c'entrano granchè.
Giusto per risponderti:
- Eclipse mi soffre anche con Pentium 4 3.00 GHz e 1 GB di RAM
- Cosa me ne faccio di J2ME? Felice della sua esistenza e di queste 
performance ma io non parlavo dispositivi mobili.
ciao
andrea

 performance ma io non parlavo dispositivi mobili.
IBM WebSphere esiste anche per Windows/x86 e Linux/x86.
E' un ambiente J2ME CDC, quindi ha AWT (con componenti nativi GTK/Win 32,
non l'AWT classico) più il resto della piattaforma ma non ha il JDBC.
Convertire un programma a questa piattaforma significa spostare
l'operatività SQL su servlet o un applicativo J2SE residente su un server
e usare un protocollo di comunicazione da definirsi.
Come ti dicevo me ne sono invaghito e avevo pensato di portarci del
software, ma decisamente non ne vale la pena, è stata una cotta temporanea.
ciao
gl

 sembra di si. Buon per me. :)
da quello che leggo l'unica differenza mi sa è che tu usi linux e io 
windows. Sarà lui alla base del problema di eclipse :D?
ciao
andrea

 scadenti *solo* per quello che riguarda l'avvio e il consumo di memoria.
Per fare degli esempi, il seguente codice su una JVM 5.0 occupa 8Mb,
mentre su di una JVM 6.0 ne occupa 7Mb:
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class Console {
    public static void main(String[] args) {
        BufferedReader input;
        String curString;
        boolean state;
 
        input = new BufferedReader(new InputStreamReader(System.in));
        state = true;
 
        while (state) {
            System.out.print("> ");
            try {
                curString = input.readLine();
                if (curString.equals("\\q")) {
                    state = false;
                }
            } catch (IOException e) {
                state = false;
            }
        }
    }
}
Enrico
P.S. su 
http://programmazione.it/index.php?entity=eitem&idItem=36603
sono riportate alcune delle novita` previste in Java 7, anche se secondo
me si sta correndo troppo

 windows. Sarà lui alla base del problema di eclipse :D?
Qualche volta l'ho usato su Windows, ma è passato tanto tempo non ricordo.
Cambia ambiente desktop di sviluppo, tanto è tutto cross-platform! :)
ciao
gl

 distribuite da IBM o Redhat)
Attento che e` una mezza fregatura. La compilazione con GCJ ti produce
un binario linkato dinamicamente alla libreria libgcj.so, e praticamente
ottieni gli stessi risultati di una applicazione java normale (a livello
di memoria occupata, a livello di velocita` non saprei dirti, non ho
verificato)
Enrico

 .NET contro C.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&lang2=java
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&lang2=gcc
Enrico

 non l'AWT classico)
Ecco, questo sarebbe interessante da vedere in una J2SE: componenti
nativi invece dei componenti AWT standard (ovviamente per essere
interessante i componenti nativi dovrebbero essere mappati con una
corrispondenza 1:1 a quelli AWT, e non aggiunti tramite librerie
esterne tipo SWT)
Enrico

>> - Eclipse mi soffre anche con Pentium 4 3.00 GHz e 1 GB di RAM
 >>
 >> Se Eclipse non ti sta dietro alla digitazione da tastiera su un P4 con
 >> 1GB
 >> di RAM hai altri problemi sulla macchina.
Confermo quello che dice GL: Eclipse non dovrebbe avere difficoltà con 
una tale macchina a meno che tu non abbia altri problemi o che la 
configurazione della memoria non sia sbagliata. Prova ad aggiungere i 
seguenti parametri nella riga di comando (questi sono quelli che uso su 
una macchina con 2 Gb di ram, tu giocaci un po'):
    -vmargs -Xmx768m -Xms384m -XX:MaxPermSize=192m
Magari è solo che il tuo workspace è troppo grande e/o hai troppi plugin 
installati per la memoria assegnata ad Eclipse.
Andrea

 Andrea
Dimenticavo, io uso windows XP

 dall'altra parte no.
Macchè: Python, Perl e Ruby hanno tutti una vm. Eppure l'avvio è del
tutto istantaneo. Non è quello il punto. 


> GTK/Win 32, non l'AWT classico)
E'B> Ecco, questo sarebbe interessante da vedere in una J2SE:
E'B> componenti nativi invece dei componenti AWT standard 
AWT se non ricordo male  e` "nativa", basta vedere come gestisce certi
"controlli"  composti come  i combo  sotto  Unix e  sotto Windows  per
rendertene conto. Java fa un wrapping uniforme degli stessi.
(Tra l'altro, sotto Unix, AWT per errore è così legato a X11 che hanno
dovuto  patchare   il  comportamento  della  JVM   per  permettere  il
funzionamento headless... E lo stesso  a volte devi avere un webserver
con X11 attivo  o un PC che non  fa un cavolo se non  tenere un server
attivo con  la variabilie DISPLAY  sul webserver che punta  al display
del PC...)


     -vmargs -Xmx768m -Xms384m -XX:MaxPermSize=192m
Ti ringrazio per i parametri, li proverò sicuramente. Escludo le altre 
cause nel senso che ho questo problema con un workspace vuoto (post 
setup). Magari con la memoria risolvo.
Ricordo che feci variazioni del genere con ZEND tempo fa per cercare di 
risolvere lo stesso problema senza alcuna differenza apprezzabile. La 
situazione mi è cambiata nettamente passando a JRokit 1.5.
ciao
andrea

     Scorpio.
Non è sicuramente la più grande lacuna, però a volte mi piacerebbe di 
più un approccio della javadoc stile msdn :) La javadoc la trovo molto 
completa, però ha il difetto che se uno non conosce o sa che deve 
utilizzare una determinata classe, è praticamente impossibile scovare 
una certa funzione!
Per fare un esempio semplice, in msdn potrei cercare una frase del tipo 
"scrivere su stdout", mentre nella javadoc devo già sapere che devo 
orientarmi verso la classe System! In questo modo magari molte 
funzionalità rimangono "nascoste" a meno di ricerche su internet o 
altro... :)

 scadenti *solo* per quello che riguarda l'avvio e il consumo di memoria.
Mah...
Io non sono un esperto di java per cui mi potrei sbagliare, pero'...
riporto una mia esperienza di qualche anno fa (puo' darsi che con le
ultime versioni del jdk sia diverso, non so)
Problema:
c'e' un server TCP/IP scritto in C che accetta connessioni da dei client
e legge dei dati dagli stessi (e poi manda una risposta).
Si deve scrivere un client in java per quel server
Stato dell'arte: ci sono vari client che si interfacciano
con quel server: alcuni in C, altri Delphi.
Il server e' fatto male (ma io, prima di scrivere il clien java non
lo sapevo).
Scrivo il client in java che si connette al server e simulo il
server sul mio PC (in C). Provo (quasi per caso) a fare un server
che accetta una connessione da un socket e poi legge byte per byte
quello che il client spedisce fino ad aver letto la dimensione dello
"stream" che deve arrivare (che aveva dimensione fissa). 
Scopriro' poi (prima di fare i test sul mio PC) che anche il server 
vero legge byte per byte.
Pero' legge da socket non bloccante e, nel ciclo di lettura implementa
piu' o meno il seguente algoritmo (sbagliando, pero' non mi rendo conto
subito dell'errore):
while (1)
{
 tenta di leggere un byte
 se ((non c'e' niente da leggere) && (al tentativo precedente non c'era
niente da leggere) allora chiudi il socket e esci dal ciclo
}
Allora anche al mio server simulato faccio eseguire il suddetto algoritmo.
Provo client e "server simulato" entrambi sul mio PC, provando anche i
client gia' esistenti con il mio "server simulato": quello che accade e'
quanto segue:
Client in C:
spedisco una struttura da circa 120 byte => il server li legge
Client in Delphi
spedisco una struttura da circa 120 byte => il server li legge
Client in java:
spedisco una struttura da circa 120 byte => accade quanto segue:
il client passa i 120 byte alla JVM. La JVM ne spedisce 1 al server, 
va a farsi una doccia, prende un caffe', 
si fa una dormitina e poi tenta di spedire
il secondo byte. Mentre passa il tempo tra la spedizione del 1. byte
e la spedizione del 2. byte => il serve in C ha ciclato piu' volte e
avendo trovato che per due o piu' cicli non c'era niente
da ricevere => chiude il socket in faccia al client.
E questo accadeva sia quando il server e il client erano entrambi
sul mio PC (PEntium 4, 1.8 GHz, Windows 2000 Professional), sia quando
il client era sul mio PC ed il server su workstation Sun (Solaris 8).
Dal mio punto di vista e' un chiaro errore di sincronizzazione
di chi ha scritto il server, ma mette in luce che in realta'
la JVM non e' "velocissima". Ripeto, roba del 2002 o 2003 per cui
magari nel frattempo le cose sono diverse, non so.
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 magari nel frattempo le cose sono diverse, non so.
In realtà da quello che hai visto non puoi trarre nessuna conclusione 
sulla velocità della JVM, o quantomeno non nei termini che si sono 
intesi fino a questo punto.
Quando si parla di prestazioni di solito si intende qualcosa di più 
"complessivo" del tempo per eseguire un solo ciclo.
Nel tuo caso il problema potrebbe essere dovuto a diversi fattori:la 
presenza di più thread all'interno della VM, l'utilizzo del JIT che 
potrebbe perdere tempo a compilare qualche classe per aumentarne le 
prestazioni, ecc.
In realtà il tuo somiglia ad un problema di Real Time, che più che avere 
a che fare con le prestazioni ha a che fare con la predicibilità dei 
tempi di risposta. In un'applicazione real time, quando eseguo 
un'operazione, più che essere interessato al fatto che, in media, ci 
metta poco, mi interessa sapere il tempo massimo entro cui 
quell'operazione verrà eseguita (e non necessariamente media bassa 
significa massimo basso).
Andrea