Newsgroup: it.comp.lang.visual-basic
Titolo: prove di velocita*

Salve. Vi sottopongo i risultati di una prova che ho fatto con un
piccolo programma che segna il tempo di decremento di un numero. Lo
stesso programma identico l'ho fatto con vb4, vb5 e 
vb.net
 2003. Ho
misurato il tempo in secondi del decremento (ottenuto con un loop di
for-next) del numero 100.000, prima sotto windows xp e poi sotto
windows 98 SE. Naturalmente le prove sono state fatte a parita* di
hardware, cioe* sullo stesso computer (un po' vecchiotto).
Ecco i risultati.
Con Windows XP: vb4 70 sec., vb5 64 sec., 
vb.net
 82 sec.
Con Windows 98 SE: vb4 65 sec., vb5 58 sec.
Non ho potuto eseguire il test di 
vb.net
 con win 98 perche* non ho
potuto creare le condizioni di runtime (avrei dovuto installare dot
net framework con obbligo di installazione di una versione piu*
recente di Internet Explorer!).
Le mie conclusioni sono che MS, tra vb4 e vb5, ha fatto qualche sforzo
nella direzione delle performances, ma tra vb5 e 
vb.net
 ha fatto un
enorme salto indietro. Ovviamente il test non e* completo, in quanto
le diverse istruzioni di vb potrebbero avere una resa diversa. Se
qualcuno ha fatto altre prove o puo* esprimere giudizi piu*
circostanziati sarei felice di conoscerli.
Nefertiti

 enorme salto indietro.
Ciņ č dovuto al fatto che il codice creato da .NET non č eseguito come
compilato, ma deve "passare" attraverso il Framework.
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it

 Con Windows XP: vb4 70 sec., vb5 64 sec., 
vb.net
 82 sec.
1) vb4 è ovviamente in PCode, vb5 è stato compilato in modo nativo?
2) Qual è il tipo di dato usato in Vb4, VB5 e VB.net?
3) E' possibile avere il codice utilizzato nei tre casi?
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

compilato, ma deve "passare" attraverso il Framework.
Domanda stupida: ma il Framework .NET non dovrebbe eseguire una
compilazione alla prima esecuzione del programma e poi utilizzare la
versione compilata le volte successive (ovviamente fino a quando il
programma originale rimanga invariato)???
Ciao
		Cristian

 programma originale rimanga invariato)???
Non ho studiato approfonditamente le specifiche del framework, ma a quanto
mi sembra di capire, il programma viene compilato ogni volta che viene
eseguito (e da qui le scarse prestazioni).
Altrimenti non saprei quale potrebbe essere la causa, perň una cosa č certa:
le prestazioni su piattaforma .NET sono di gran lunga inferiori rispetto
alle altre versioni di VB.


 inferiori rispetto alle altre versioni di VB.
Mica vero. Almeno non sempre vero.
Saluti.

 alle altre versioni di VB.
Non mi risulta proprio :)
Ecco i test che ho fatto io:
Un progetto con un form e un pulsante, nel codice del pulsante:
Su un Celeron 800
VB6
    Dim t As Double
    Dim i As Long
    Dim x As Long
    t = Timer
    For i = 0 To 100000000
        x = x + 1
    Next i
    MsgBox Timer - t
interpretato: ~10 sec.
compilato nativo: ~1sec.
VB.net
    Dim t As int32
    Dim i As Int32
    Dim x As Int32
    t = DateTime.Now.Second
    For i = 0 To 100000000
    x = x + 1
    Next i
    MsgBox(DateTime.Now.AddSeconds(-t).Second)
compilato IL (prima esecuzione): ~1sec
Ho provato anche a aumentare il loop fino a 1.000.000.000, e il risultato
non cambia: ~8 secondi sia per VB6 compilato che per VB.net


 Non mi risulta proprio :)
Sicuramente mi sto sbagliando, ma ho notato che tutte le applicazioni di
prova che sto creando con 
vb.net
 vanno molto più lente rispetto a quelle
vb6.
Probabilmente sarà dovuto al fatto che per ora eseguo in modalità debug?
Però VB6 in modalità debug mica va così lento....
Non appena finisco di studiarmi il libro su 
vb.net
 passerò a studiarne uno
approfondito sul framework, in quato vi sono molte cose a me oscure.
Comunque grazie per le varie precisazioni... non si finisce mai di imparare
:-)



1) Si*, giusto. Il tipo di compilazione ottimizzato potrebbe spiegare
la maggiore velocita* dell'eseguibile compilato con vb5.
2 e 3) L'applicazione e* fatta con un form contenente due controlli di
testo, due bottoni e un timer. Si scrive un numero in Text1 e si
clicca il primo bottone che esegue il loop di decremento. Le
interruzioni del timer permettono il conteggio del tempo. Ecco le
istruzioni prese da 
vb.net
. 
Public Class Form1
   Inherits System.Windows.Forms.Form
   Dim tempo As Double
.......
.....
   Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
      Dim num1 As Integer, numsec As Double
      If Len(Trim(TextBox1.Text)) > 0 Then
         Timer1.Enabled = True
         num1 = Val(TextBox1.Text)
         numstart = tempo
         For num1 = num1 To 0 Step -1
            numsec = tempo / 1000
            TextBox1.Text = Format(num1, "#######0")
            TextBox2.Text = Format(numsec, "###0.00")
            Application.DoEvents()
         Next num1
         Timer1.Enabled = False
      End If
   End Sub
   Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
      End
   End Sub
   Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
      tempo = tempo + Timer1.Interval
   End Sub
End Class

 [SNIP]
Si, ho trovato lo stesso identico codice in un articolo della pubblicazione
"Salumeria e programmazione artigianale". Ma come diamine pretendi di fare
un test comparativo con un codice del genere?!?
Lokar.senza.parole
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
Statuto: 
http://www.it-lang-vb.net/docs/Statuto.txt
UGIdotNET - 
http://www.ugidotnet.org

 un test comparativo con un codice del genere?!?
Ecco... non ho risposto perchè non trovavo le parole giuste :P
Il tuo post esprime correttamente il mio pensiero. :)
Ciao

 Il tuo post esprime correttamente il mio pensiero. :)
Scommetterei che la "prima stesura" di quel post, si avvicinava ancora di
piu' al tuo pensiero.
L'ho riscritto almeno 3 volte per non beccarmi una querela per insulti e
diffamazione...
Lokar


 piu' al tuo pensiero.
Sě, credo di sě.
Anch'io avevo iniziato a rispondere ma poi ho premuto il tastino con la 
X perchč non ero molto convinto di quello che stavo facendo ;)
Ciao


Ooops! Non avevo notato di avere scritto sulla carta del salame.
Errata corrige: al posto di 'numstart=tempo' leggasi 'tempo=0'.I
signori professori farebbero cosa piu* utile e meno indecente se
volessero sottolineare cio* che tanto li offende. E poi dovrebbero
spiegare perche* la nobile arte del RAD dovrebbe essere proibita a
salumieri e artigiani mentre e* permessa, evidentemente, ad allegre
comari.
Nefertiti

 permessa, evidentemente, ad allegre comari.
Apprezzo la sottile ironia ma non provo neanche a "commentare" il codice da
te postato (cosa che volevo fare all'inizio) perche' non saprei da dove
partire.
Basti dire che usare TextBox (testo) per memorizzare numeri (convertiti e
riconvertiti), Format per formattarli, DoEvents (!!!) per avere un refresh
*grafico* del form, calcolare il tempo trascorso *ad ogni ciclo* NON puo'
*evidentemente* ed *assolutamente* dare una stima comparativa *valida*.
Copio-incollo il codice usato da Zanna (post di questo thread) sperando di
illuminarti sui meccanismi da adottare per effettuare un valido test
comparativo:
<Zanna>
VB6
    Dim t As Double
    Dim i As Long
    Dim x As Long
    t = Timer
    For i = 0 To 100000000
        x = x + 1
    Next i
    MsgBox Timer - t
interpretato: ~10 sec.
compilato nativo: ~1sec.
VB.NET
    Dim t As int32
    Dim i As Int32
    Dim x As Int32
    t = DateTime.Now.Second
    For i = 0 To 100000000
        x = x + 1
    Next i
    MsgBox(DateTime.Now.AddSeconds(-t).Second)
compilato IL (prima esecuzione): ~1sec
Ho provato anche a aumentare il loop fino a 1.000.000.000, e il risultato
non cambia: ~8 secondi sia per VB6 compilato che per VB.net
</Zanna>
Per riassumere:
- stesso tipo di dati, stesso identico codice;
- il tempo si misura *prima* e *dopo* il ciclo non *durante*;
- durante il ciclo si eseguono istruzioni *elementari*, ed in particolare si
fa a meno di funzioni delle cui non si conosce il codice e che possono
essere implementate in modo diverso da linguaggio a linguaggio (vedi Format)
e comunque tali istruzioni non devono essere influenzate da fattori quali
grafica, ed operazioni del sistema operativo;
- in particolare il test vanno eseguiti senza altri processi in esecuzione
che possono impegnare il processore "casualmente".
Spero che tu comprenda il nostro "sgomento" nel vedere infrante praticamente
_tutte_ le regole basilari per effettuare un test comparativo "valido".
Lokar
P.S. l'apostrofo : ' (ASCII 39) e' fra i caratteri della codifica ascii
standard, perche' mai la sostituisci con un asterisco?


 ascii standard, perche' mai la sostituisci con un asterisco?
Lo uso anche io (e molti altri) perchè con quotefix si vede il testo fra i
due asterischi in grassetto.
*ciao* = grassetto
_ciao_ = sottolineato
ecc...


 ecc...
Ok, ma che c'azzecca l'apostrofo? ;-)

 essere implementate in modo diverso da linguaggio a linguaggio (vedi Format)
Tra l'altro occorrerebbe usare funzioni equivalenti dei rispettivi 
linguaggi.
La Format in VB.net è molto più pesante perchè utilizza substrati per la 
retrocompatibilità.
In .Net sarebbe opportuno usare la .ToString(formato)
Lo stesso dicasi per la Val: Double.Parse(stringa)
Non si possono comparare due linguaggi diversi usando funzioni che "si 
crede" uguali.
Ciao

 _ciao_ = sottolineato
:) Io queste funzionalità le ho di default nel reader di Mozilla :)
E anche la firma io la vedo in grigino :PPP
Ciao

 Ok, ma che c'azzecca l'apostrofo? ;-)
Dicevo solo che non utilizza gli asterischi come apostrofo, ma solo perchč
vuole portare in grassetto la cosa.


 _ciao_ = sottolineato
Eh gia', se rileggi il mio post, noterai che anche io li uso per rendere il
testo _corsivo_ o *grassetto* ma non mi spiego (e chiedevo in PS) perche'
mai per scrivere parole come velocita' (vd titolo del post) nefertiti usa
un'asterisco al posto dell'apostrofo. E ancora non me lo spiego.
Lokar


 non me lo spiego.
Caspita, non l'avevo notato.


Cari Lokar e Zanna, apprezzo lo sforzo sovrumano che avete fatto,
vincendo il vostro disgusto, per esporre finalmente le vostre tesi
fondate, evidentemente, su uno studio approfondito e, probabilmente,
quotidiano. Vi ringrazio a nome di tutti i poveracci come me che
arrancano dietro a un pacchetto faraonico (da cui, forse, il mio
nickname) come 
vs.net
, che, per le condizioni in cui mi trovo (450
mhz, 128 mb di ram e con un vecchio lettore di cd che da` errore su
due dei 5 dischi di installazione) e` quasi inaccessibile (oltre che
ufficialmente sconsigliato da MS per inadeguatezza ai requirements). 
L'asterisco io lo usavo solo come accento per non usare in usenet le
lettere accentate. Mi sembrava che fosse la regola originale stabilita
dai padri della 'netiquette' per usenet :-)
Considerate ora l'esperienza quasi kafkiana di chi voglia accostarsi
al mondo del .net, specie nel caso che abbia gia` investito i
necessari 1500-2000 euro piu` l'adeguamento dell'hardware e piu`
eventuali corsi. Ti mettono in mano 5 dischi e quando vai per iniziare
l'installazione, su qualunque tipo di sistema, ti vedi rispondere:
"Tsk, tsk, tsk, ti manca qualcosa. Mettiti in connessione che ti
aggiorno". Naturalmente te ne guardi bene, cerchi di informarti e,
dopo qualche giorno di ricerca, scopri che devi installare due
pacchetti di .framework scaricabili dal sito MS. Se provi ad
installare .framework su Win98, ti viene imposto un IE 5.1 (ma che
c'entra?). Se provi su Win2000, non mi ricordo in quale momento
preciso, ti viene imposto un IE 5.5 (ma e` una fissazione!). Su XP va
tutto bene, ma se usi la transizione automatica, poi devi provare a
correggere centinaia di errori.
Riguardo alla routine da usare per misurare le velocita` degli
eseguibili prodotti con versioni diverse del VB in diversi ambienti,
mi e` ben chiara la vostra contestazione: si devono testare i tempi
netti dell'esecuzione delle istruzioni VB e non gli appesantimenti
dovuti alle particolari condizioni ambientali. Percio`, voi dite, e`
opportuno evitare il 'doevents' e le conversioni di formato, e bisogna
rilevare il tempo prima e dopo e non durante lelaborazione di test.
L'approccio e` perfetto, scientifico, ma rimane da decidere quali
istruzioni inserire nel loop per ottenere un test vicino alla
completezza. E poi bisognera` pure rilevare l'entita` dell'apporto
ambientale (cioe` quella cosa che, credo, si chiami 'overhead') data
dal sistema operativo, ovviamente non invalidato dalla presenza di
tasks diversi da quello del test.
Forse non si e` notato abbastanza che il mio test, per quanto ingenuo
e poco ortodosso, e` stato fatto con due sistemi operativi diversi. Le
cose che vorrei appurare sono due: 1) come e perche` gli eseguibili
prodotti con le diverse versioni del VB abbiano velocita` diverse (e
di questo qualcosa mi avete aiutato a capire); 2) come e perche` lo
stesso eseguibile abbia velocita` diverse con diverse versioni di
Windows (98se e XP).
Fino ad ora abbiamo capito che gli eseguibili fatti con VB5 sono
superiori a quelli fatti da VB4, a condizione che si usi la
compilazione ottimizzata offerta da VB5. Poi abbiamo appreso da Zanna
che certe istruzioni del 
vb.net
 possono risultare piu` pesanti perche`
passano attraverso il .framework e/o perche` devono rispettare la
compatibilita` con il VB6. E questo ci dovra` indurre a usare tipi di
istruzioni introdotte da .net al posto di quelle vecchie. A questo
proposito, mi sarebbe piaciuto trovare, nel documento di MS sulla
transizione da vb6 a 
vb.net
, o comunque nel sito di MS, una tabella
completa della corrispondenza tra istruzioni VB6 e istruzioni del
vb.net
. Se qualcuno ne ha notizia, me lo faccia sapere, per favore.
Ora pero` io devo interrompere i miei esperimenti fino all'acquisto di
hardware piu` potente e ad una migliore disposizione psicologica.
Grazie a tutti.
Nefertiti