Newsgroup: it.comp.lang.visual-basic
Titolo: Prestazioni diverse tra l'IDE ed il run-time

Salve a tutti,
ho un problema con una applicazione che sto scrivendo in VB6. Mi sono
scontrato con un intollerabile peggioramento delle prestazioni passando
dall'ambiente IDE alla versione compilata.
La procedura incriminata sostanzialmente istanzia una serie di ogetti (circa
600). Eseguita dall'IDE dura non piu` di 10 secondi, la versione compilata
ci impiega oltre 5 min. Qualche suggerimento?
Grazie, Massimo

 ci impiega oltre 5 min. Qualche suggerimento?
Sulla stessa macchina e facendo le stesse cose? Non ci credo!
Aggiungo: Anche se le prestazioni dell'IDE non sono male-male, in genere con
l'EXE si viaggia un peletto meglio.

Pardon (perchè la differenza ci sarebbe, l'ho letto qui), stai mica parlando
di .NET, vero?
E, da che ci siamo, per "versione compilata" ti riferisci all'esecuzione
dell'EXE già disponibile, non alla sua creazione (compilazione, appunto),
vero?!!!

 ci impiega oltre 5 min.
Ipotesi ipotetica ;-) : magari nell'IDE, per poterci lavorare, gli oggetti
vengono istanziati già al caricamento del sorgente ?
Bye, G.

 vengono istanziati già al caricamento del sorgente ?
Paperino, 5 minuti? Continuo a non crederci, nemmeno con 600 oggetti.

 ci impiega oltre 5 min. Qualche suggerimento?
E' veramente strano.
Perň puň esserci qualche differenza nel caso di eventi particolarmente
intricati.
Puoi fare questa rapida verifica: compila in PCode.
Il compilato in PCode č *esattamente* come se girasse nell'IDE (solo che
salta alcuni controlli come i breakpoint e il debug, risultando
leggerissimamente piů veloce).
Se cosě non hai problemi o tieni la versione PCode (che nel 99% delle volte
non ha niente da invidiare alla compilata in codice nativo) oppure cerchi di
isolare il problema.
Ciao
--
y = f(
http://neodatatype.interfree.it/index.html
)

 Paperino, 5 minuti? Continuo a non crederci, nemmeno con 600 oggetti.
...'ffettivamente...
Magari c'è qualcosa che va in time out, o qualcosa linkato in rete,
o... BOH !
Comunque una possibilità sarebbe aggiungere delle istruzioni di
log, per vedere cosa fa effettivamente il prog in questione all'avvìo.
Se nel log poi vedi, per esempio:
...
...
18:01:59 Carico oggetto LasagneAlRagu
18:02:05 Carico oggetto CavolettoDiBruxelles
18:02:07 Carico oggetto PizzettaBianca
18:02:09 Carico oggetto ProsciuttoCotto
18:02:13 Carico oggetto Peperone
18:06:45 Carico oggetto UovoFritto
18:06:53 Carico oggetto CosciaDiPollo
18:07:01 Carico oggetto Spinaci
...
...
Ti accorgi subito, guardando i tempi, che il prog non ha digerito
l'oggetto Peperone (nel caso si potrebbe provare a sostituirlo
con un Pomodoro, o in alternativa aggiungere un oggetto
CitroSodina o BicarbonatoDiSodio).
Bye, G.

 CitroSodina o BicarbonatoDiSodio).
LOL!
Perň (visto che non si diceva il contrario, nč ancora c'č stata conferma o
smentita) io davo per scontato che si parlasse della stessa macchina e,
ovviamente (sennň "diciamolo"), dello stesso ... programma e quindi dello
stesso menů, leggero o pesante che sia.

 stesso menù, leggero o pesante che sia.
Però loggando puoi scoprire se il problema è in un particolare
oggetto (o tipo di oggetti) e restringere il campo. Confrontando
i log dell'IDE e dell'eseguibile puoi capire altre cose. Tra l'altro
in questo caso il codice di log dovrebbe se possibile essere
inserito nell'oggetto stesso, in modo da vedere quando viene
effettivamente istanziato l'oggetto.
Bye, G.

 effettivamente istanziato l'oggetto.
Vero, ma nelle stesse identiche condizioni (basta dire sulla stessa identica
macchina), lo stesso programma deve fare le stesse cose nei due ambienti.
... Ehm, tranne il caso di eventi in ordine diverso (vedi altro post):
So per certo (no, ora non chiedermelo l'esempio, fidati) che la sequenza
degli eventi _può_ essere occasionalmente diversa (pur escludendo presenze
di Debug.Print eseguiti nell'IDE), ma, a quel punto, _sistematica_, fra IDE
e EXE. Metti che ci sia una serie di istruzioni "importanti" che vengono
attivate nell'EXE prima (o dopo) rispetto all'IDE solo perchè un certo
evento si verifica nella sequenza non prevista dal programmatore e
sconvolgono la logica della procedura e ... abbiamo fatto bingo.

 sconvolgono la logica della procedura e ... abbiamo fatto bingo.
L'unico caso in cui facendo bingo si perde anziché vincere...
Bye, G.

 L'unico caso in cui facendo bingo si perde anziché vincere...
Già!
Ohhhh, io vado a nanna, neh!
E tu al lavoro!, schiavo. ;-)
Bye.

 E tu al lavoro!, schiavo. ;-)
A nanna anch'io :-PPPPPPP
Bye, G.

 Bye, G.
Grazie per questo suggerimento. Ho scoperto l'arcano.
Nel metodo Class_Initialize() di una delle classi coinvolte, venivano
letti dei valori dal Registry di Windows. Questa lettura del Registry
risulta velocissima se il pgm viene eseguito nell'IDE, estremamente lenta
nella versione compilata.
Ho eliminato l'accesso al Registry ed ora anche l'exe e` una scheggia.
Grazie a tutti, M.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it