Newsgroup: it.comp.lang.visual-basic
Titolo: [!].NET/VS6/Java: Prestazioni a confronto

Link "rubato" da un post di Giobibo su microsoft.public.it.dotnet.vb.
http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=203
Interessante l'articolo, ma anche i commenti a fine pagina.
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

Interessante l'articolo, ma anche i commenti a fine pagina.
Sarebbe molto piu' interessante se pubblicassero anche il codice
effettivamente usato. Quei risultati, in mancanza del sorgente
applicato, non significano nulla.
-- 
ciao, hal

 Lokar
ossia che non c'è un risultato uguale? eh eh....che M$ dice una cosa...e
tutti un altra una diversa dall'altra?
ad uno viene più veloce VB di VC#...e già senza provare mi si alzano le
sopracciglia!
:-)


tempo fa su DEV c'era un articolo
in cui si provava la velocità dei vari compilatori,
non riesco a trovarlo, ma mi ricordo benissimo
che VB si comportava benissimo e le dava
anche al compilatore borland non so se
pascal o c++.
mah.
Continuerò a cercare.
            danilo

 Interessante l'articolo, ma anche i commenti a fine pagina.
Interessante in linea teorica, ma in pratica è già da qualche anno che non
mi capita di dover scrivere un programma per il quale la velocità di
elaborazione sia un problema per un mio cliente.
Anche  se si trattasse di differenze di velocità nell'ordine del 100% tra un
linguaggio e l'altro (e sto ovviamente esagerando) si noterebbero solo
lavorando su applicazioni particolari e/o su moli da dati gigantesche, ma in
quel caso diventano comunque più importanti le performance del motore di
database che quelle del linguaggio.
Il problema velocità è legato alla percezione che l'utente ha del compito
svolto. Se l'utente vede una barra di avanzamento che avanza lentamente ma
costantemente, è pronto ad aspettare anche un paio di minuti. Se si trova di
fronte ad un messaggio "Attendere prego" con un conto alla rovescia del
tempo stimato che si modifica in base alla velocità di avanzamento
dell'elaborazione, può aspettare anche delle ore.
Esemplificando, Windows con il suo messagebox di copia in corso fa
arrabbiare perché su grandi moli di dati copiati sbaglia i tempi, e non
perché ci mette molto tempo. Sulla cancellazione invece fa arrabbiare perché
ci mette una enormità di tempo, rispetto a quello che chiunque abbia visto
in azione un Deltree sotto Dos possa sopportare.
Con questi due esempi è chiaramente esplicitato che quello che conta è il
tempo che l'utente presume debba impiegare l'elaborazione, e non il tempo
effettivamente impiegato.
In entrambi i casi, una differenza anche del 100% è ininfluente. Se aspetti
un minuto o due non cambia gran ché, perché oltre ai 20-30 secondi l'utente
smette di guardare la barra e si prende un caffe. Lo stesso avviene per la
differenza tra un'ora o due ore, perché per elaborazioni di quel tipo si
usano macchine dedicate sulle quali le elaborazioni vengono lanciate alla
sera, o in pausa pranzo, e non vengono controllate se non una o due volte al
giorno.
L'unico problema di velocità su cui l'utente si lamenta è quando si passa da
mezzo secondo a 1 o 2. Si tratta in realtà dei passaggi di stato tra il "ci
vuole poco" e "uff, mi tocca di aspettare". Questi problemi di solito si
eliminano con una sapiente pianificazione dell'elaborazione, che può spesso
essere spezzata, rimandata, o eseguita in background.
Si tratta dei rallentamenti "visibili". Ad esempio se il programma fa un
refresh di tutta la form ogni volta che si pigia un tasto (magari per colpa
di un ricalcolo), l'utente troverà insopportabile anche un tempo di attesa
minimo tra un tasto premuto e l'altro. A quel punto basta evitare il refresh
automatico e inserire un pulsante "ricalcola", e l'utente non si lamenterà
più perché sarà lui a pianificare quando dovrà avvenire la "perdita di
tempo".
Insomma, il fatto che un programma reagisca rapidamente o sembri arrancare
non dipende quasi mai dal linguaggio di elaborazione che si usa.
Certo, ci sono eccezioni: ad esempio scrivendo un videogame in VBA non ci si
possono aspettare prestazioni esaltanti, ma stiamo parlando di casistiche
molto particolari che nella quotidianità del lavoro non si incontrano
praticamente mai.
Molto più importante della velocità di elaborazione è invece la velocità di
realizzazione. Ma per quello di test comparati tra linguaggi non se ne
vedono molti. ;-).
Just my 2 eurocents, ovviamente.
Ciao
*Roby*

vedono molti. ;-).
clap clap :-)
-- 
ciao, hal

 tra linguaggi non se ne vedono molti. ;-).
Sinceramente direi che la maggiore priorità andrebbe alla qualità
(stabilità, robustezza, chiarezza, modifica, estendibilità, ecc...) del sw e
*solo dopo* alla velocità di realizzazione.
Ciao.
--
BSD is for UNIX lovers - linux is for Windows haters

 *solo dopo* alla velocità di realizzazione.
clap clap :-)
j.quote


wrote:

eh eh, anche il buon H.P.L. non si smentisce mai :-)
-- 
ciao, hal

sono assolutamente d'accordo.......
ritengo che al giorno d'oggi è molto più importante fare un programma
"espandibile" o, come dice Microsoft, scalabile......concetto con cui sono
andato d'accordo per anni utilizzando ADO come piattaforma per l'accesso ai
db.
Ho girato tutti i miei software da Access verso SQL-Server (MSDE), senza
riscrivere una sola linea di codice.......
i miei software hanno guadagnato enormemente di velocità, e non lo dico così
per dire......
operazioni piuttosto pesanti, che sotto Access portavano via 2-3 minuti,
venivano risolte in 10-15 secondi, a beneficio dell'utente. Ovvio, se poi
uno vuole sfruttare bene il db che utilizza, deve un attimo riconsiderare
bene il codice: io, per esempio, ho trasferito sul server parte del codice
vb (scrivendo stored-procedure, ad esempio).
poi, diciamoci la verità, oggi per fare un buon prodotto occorre rispettare
certi standard: form ben fatti, interfacce elaborate (stile Office, barre di
Outlook e così via), perciò un po' di velocità la si deve cmq
perdere........
però se ne guadagna in "soddisfazione" dell'utente, soprattutto, come diceva
giustamente Piazzolla, si crea una sorta di compromesso tra
velocità-interazione utente-benifici. Per questo, son d'accordo anche con
lui.....
clap clap a tutti e due!!!!
:-)))
good coding!!!
--
Igor Damiani
ig...@igordamiani.it
http://www.igordamiani.it
ICQ : 11847262

 modifica, estendibilità, ecc...)
Su stabilità e robustezza siamo d'accordo. E' la prima cosa che il cliente
guarda.
Per quanto riguarda il resto, spesso si tratta di sinonimi di "velocità di
realizzazione". Il commento di Igor, pochi messaggi più sotto, esemplifica
questa l'identità tra "estendibilità" e "velocità di realizzazione".
Discorso a parte va fatto invece per la "chiarezza"; si tratta di un vero
plus solo quando hai a che fare con progetti almeno "medi" e con clienti che
sono disposti a pagarla. Se questo non avviene, il grado di chiarezza che si
utilizza nel progetto è quello standard. Ciò significa che, ad esempio, alla
fine dello sviluppo ti guardi bene dal produrre la documentazione tecnica
del sorgente, e che tendi a riciclare il più possibile parti di codice che
hai già scritto (approccio solitamente corretto, ma dal quale è meglio non
farsi prendere la mano).
In un mondo perfetto, tutti i software sarebbero perfetti, ma purtroppo non
siamo in un mondo perfetto. Come al solito si tratta di trovare la giusta
soluzione di compromesso.
Peraltro, visto che si parlava di confronti tra linguaggi, stabilità e
robustezza possono anche dipendere dal linguaggio, ma chiarezza,
modificabilità ed estendibilità dipendono principalmente da come si scrive
il codice.
Ciao
*Roby*

 dipendono principalmente da come si scrive il codice.
Dipendono eccome dal linguaggio. Se, nell'esempio di cui sopra il linguaggio
non avesse avuto le costanti....
