Newsgroup: it.comp.lang.visual-basic
Titolo: Compila in P-Code o In nativo... Differenze Basilari?

Come da oggetto vorrei chiedere al Rispettato NG che differenza c'č tra la
compilazione in P-CODE e quella in codice Nativo?
Sicuramente queste cose sono l'ABC di VB, ma tecnicamente parlando sono
distante anni luce dalla perfezione....
Grazie e Buon lavoro.

 distante anni luce dalla perfezione....
No, sono l'ABC della programmazione :)
Ciao

 essere eseguito dal processore.
Quindi un programma VB compilato in codice nativo non ha bisogno della
libreria MSVBVM6.dll? Mi pare strano...


Non ha detto questo...
La Msvbvm60.dll contiene, tra l'altro, tutti i controlli impliciti...
nonchè il codice (binario) per la creazione dei form, per la gestione degli
oggetti, etc, etc, etc...
ciao
ugo

 oggetti, etc, etc, etc...
questa è una superFAQ a casa MS
all'annuncio della pubblicazione di VB5 i giornali si sono tuffati a
capofitto
sul compilatore in codice nativo scrivendo immani idiozie sulla mancata
necessità della DLL di runtime.
ti consiglierei di leggere i post vecchi di questo NG, ma si tratta di post
datati
1997 e credo introvabili :-)
--
Fibia "Sakamoto" FBI
E-mail: 
fibi...@hotmail.com
ICQ UIN 63586057
Sito Personale: 
http://www.geocities.com/fibiafbi
VB Simple: 
http://vbsimple.virtualave.net
Membro #26 delle Mitiche Brigate Takahashi sezione Sud

 passare la fase di interpretazione.
[Tratto da MSDN]
Da test eseguiti risulta che il 5% del tempo di esecuzione totale delle
applicazioni client viene in genere utilizzato per l'esecuzione del P-code.
Di conseguenza, se l'esecuzione del codice nativo fosse istantanea,
l'utilizzo di tale tipo di codice per questi programmi porterebbe a un
miglioramento delle prestazioni anche del 5%.
Una pressione del tasto F1 spiegherebbe molte più cose di quante ne sono
state dette in questo thread :)
--
Fibia "RTFM" FBI


 sorgente VB).
[SNIP]
Aggiungo anche che, in particolare per progetti medio-grossi, il tempo di
compilazione in P-Code e' notevolmente minore della compilazione nativa, per
cui potrebbe essere usato temporaneamente in fase di debug, quando si ha
bisogno di usare direttamente l'eseguibile/dll piuttosto che l'IDE di VB,
per poi passare alla compilazione nativa per la versione di release.
Ciao
--
Luca Dormio
luca....@tin.it

 state dette in questo thread :)
Gia', comunque trovo che il 5% sia una stima abbastanza cauta; per l'appunto
si accenna a "applicazioni client" intese probabilmente come classica
applicazione VB (frontend per un qualche DB ecc...) dove in effetti le
performance migliori possono non essere notate; come diceva Mr. Hardcore VB
"Il codice nativo non aiuta il tuo hard disk/network ad andare piu' veloce"
;-)
D'altra parte le "particolari condizioni" che citava Roal possono essere
identificate, per fare un esempio riscontrato di persona, con un
applicazione che fa largo uso di array: in questo caso la differenza e'
veramente notevole e riscontrabile a occhio nudo...



ehmmm... ti dirò che a tutt'oggi posso riconfermarti quell'affermazione
(ebbene sì... sono stato io :P)
In particolare, avevo notato, ed è abbastanza visibile ad occhio nudo su
macchine non proprio performantissime, un miglior tempo di "avvio"
dell'applicativo, particolarmente per quanto riguarda il caricamento
iniziale del/dei form dell'applicazione.
Presumo che tale comportamento sia proprio legato all' "intimo legame"
(sic...) che unisce eseguibili Vb e il rispettivo runtime...
In tutte le altre situazioni, ovviamente, valgono le tue considerazioni.
ciao
ugo


Io lo sapevo che la libreria di run-time ce la dovremo portare appresso per
sempre, ma la speranza è l'ultima a morire...

 1.05 = 0s).
Ah, ah, ah, ah, ah! Ripassa la matematica, ah, ah, ah!
Il 5% di zero secondi è zero secondi, quindi zero secondi più "l'IVA" del 5%
fa sempre zero!

 fa sempre zero!
Scusa, e lui invece cos'ha detto?
Ciao
Alfonso

 variabile impazzita. Molto meglio fare i test sul prodotto finale.
Infatti io predico male e razzolo bene, perche' in realta' compilo
praticamente sempre in nativo :-)
Comunque, non usando in genere le ottimizzazioni avanzate, non ho mai
riscontrato incongruenze tra le due compilazioni... d'altra parte questo non
dimostra nulla perche' sono anche uno di quelli a cui il SP4 funziona come
un violino :-)



Se ti consola, io sono un altro... :-P
ciao
ugo

variabile impazzita. Molto meglio fare i test sul prodotto finale.
Vero, io sto ereditando ( si :((( mi hanno scaricato la patata
bollente)  un programma  in VB che  in P-CODE non va, in compilato si,
misteri ....
Ciao
 
-----------------------------------------
Alessandro Bilato 
ale...@tin.it
http://www.geocities.com/abilato/

 entrambi i casi.
Ho riscontrato anch'io miglioramenti prestazionali di programmi in P-Code
rispetto al nativo.
Si tratta di software che accedano a database.
Facendo dei tests su algoritmi di calcolo numerico le prestazioni del codice
nativo sono effettivamente 15-20 volte più veloci del P-code.
Ciao, Simone


Fatico a credere che esista un'interazione tra cache dbms/ado o carico della
rete con il tipo di compilato vb...
Propenderei semmai per una migliore integrazione del compilato p-code con la
"macchina virtuale Vb" (chiamiamola cosě che Ms č contenta... :-P ) e di
quest'ultima col motore Ado/Oledb di quella ottenibile dal codice compilato
in nativo.
Ferme restando le altre argomentazioni, of course...
ciao
ugo