Newsgroup: it.comp.lang.visual-basic
Titolo: Native Code 200% + veloce del P-Code ??!!!??

Questa è la pubblicità ufficiale Microsoft  sulle eccezionali prestazioni della compilazione Native
Code.
Ho cominciato a nutrire sospetti, quando ho visto girare un nostro gestionale piuttosto grosso su un
133 Mhz con 32 MB di RAM: prestazioni deludenti.
Il fatto è che abituati a sviluppare con PIII a 190 MB di Ram, si rischia di essere un pochino
"fuori dal mondo"!
Per pura curiosità abbiamo ricompilato il tutto in P-Code: che ci crediate o no le prestazioni
complessive migliorano sensibilmente.
Soltanto una procedura d'aggiornamento Batch piuttosto onerosa è (visibilmente) più veloce nella
versione Native Code.
Come spiegate questo paradosso?
Siamo dei visionari?
Ciao a tutto il ng.
Luca

No, non siete visionari.
Anch'io ho notato fenonomeni simili.
La spiegazione che mi do, č legata alla struttura della "Virtual Machine" (o
runtime come lo si chiamava una volta) di Vb.
Fondalmentalmente ritengo che il problema sia nei metodi grafici e nei
controlli interni di Vb.
Se compilo in p-code, l'integrazione a run-time tra il mio applicativo e la
Virtual Machine č totale, l'applicativo gira in un ambiente legato
strettamente alla dll runtime.
Se compilo in codice machina, viceversa, le chiamate alla dll Vb sono quelle
che un qualsiasi programma compilato C fa ad una qualsiasi dll, quindi
leggermente piů lente.
Il risultato č quello che entrambi abbiamo notato: l'incremento di
prestazioni del codice compilato c'č, eccome, ove viene eseguito codice,
mentre viceversa c'č un decadimento delle prestazioni ove vengono fatte
chiamate alla dll runtime di Vb, ovvero ogni volta che uso un controllo
interno o creo un form Vb.
Quindi: compilo in native code se il mio applicativo richiede lunghe
esecuzioni di codice, compilo in p-code se ho bisogno uan rapida
visualizzazione.
Questa almeno č la mia impressione, non suffragata da conferme ufficiali Ms.
ciao
ugo

Sě, č molto probabile che tu abbia fatto centro Ugo.
Comunque č sconfortante dover scoprire certe cosuccie da soli, a dispetto delle "versioni
ufficiali".
O non conoscono a fondo i prodotti che vendono, o ci raccontano un bel pacco di balle.
Vabbč, sono le leggi del mercato!
Grazie, Luca

Dura legge del mercato!
D'altronde ho conosciuto sviluppatori che compilano in codice macchina solo
"per rendere più difficile la decompilazione da parte dei pirati"...
Quando si arriva a scelte maniacali, dal mercato arrtivano risposte
maniacali.
Certo sarebbe più gradito che "mamma Ms" fosse un tantinello più chiara in
relazione alle caratteristiche tecniche dei suoi prodotti.
Un altro bell'esempio sarebbe Ado: splendido progetto da tantissimi punti di
vista, ma ci sono uscito pazzo la prima volta che ho steso delle classi di
utilizzo degli oggetti Ado: la documentazione era praticamente inesistente
sui Provider Oledb e MOLTO carente su tutto il resto: ho dovuto procedere
per test. E si era alla Ado 2.0!
Tra l'altro hanno questo maledetto vizio di cambiare le carte in tavola
senza avvisare i giocatori: vedi 
p.es
 il supporta alle tabelle dbf nelle
varie versioni di Dao 3.5/3.6/4.0 e di Ado 2.0/2.1/2.5...
ciao
ugo

 wrote in message
news:8srm5d$u2$1...@pegasus.tiscalinet.it...
