Newsgroup: it.comp.lang.visual-basic
Titolo: SELECT CASE oppure IF...THEN

Immaginate di avere 160 valori da controllare, secondo voi č meglio un ciclo
cosě:
SELECT CASE
CASE 1
CASE 2
ecc...
END SELECT
oppure
IF a=1 THEN
END IF
IF a=2 THEN
END IF
ecc..
Se faccio girare i due cicli "passo-passo" mi sembra che entrambi si
comportino allo stesso modo, cioč che controllino tutti i CASE e tutti gli
IF.
Ciao
                 Pixel

 SELECT CASE
Ma non so perché If then else sembrano più prestazionali.. :(
            Ciao
                    Allanon

Concordo per il discorso della chiarezza di codice.....
Mi rimane il dubbio per la velocità (che purtroppo nella mia applicazione è
fondamentale).
Grazie per la risposta
                                  Pixel

Grazie....
Mi affido alle tue conoscenze di "druido" e tramuto il codice in IF...THEN.
Ciao
                                                Pixel

 ha scritto nel messaggio
news:KEJV6.6028$Ea.2...@news.infostrada.it...


Le prove non sono possibili (o almeno io non riesco) in quanto
l'applicazione deve elaborare i dati in arrivo da 10 server IRC e di
conseguenza ci sono una serie di fattori come:
- velocità di connessione
- stato del server
- elaborazione dei dati in corso
ecc...
che influenzano l'eventuale test...
Gazie ancora per l'interessamento ma credo che terrò buono il parere di
Allanon (ne vale la pena solo per il nick).
Ciao
               Pixel

> SELECT CASE
A> Ma non so perché If then else sembrano più prestazionali.. :(
Hai fatto  misure ?  Perché a naso  tra i  due non ci  dovrebbe essere
differenza. A me pare si tratti sempre di una sequenza di comparazioni
tra il contenuto della variabile e i literals.
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 tra il contenuto della variabile e i literals.
Anzi a naso potremmo dire che si dovrebbe pure risparmiare un po' di
caricamenti tra RAM e registri del processore... però alla prova pratica...
:(
E non é l'unica sorpresa... l'operatore di elevamento a potenza (^) é meno
veloce di un ciclo con le moltiplicazioni e non credo che supporti potenze
frazionarie...
            Ciao
                    Allanon

> tra il contenuto della variabile e i literals.
A> Anzi a naso potremmo dire che si dovrebbe pure risparmiare un po' di
A> caricamenti tra RAM e registri del processore... però alla prova pratica...
A> :(
Ovvero ? Hai fatto delle misure che dicono che gli if-then-elseif...end if
sono più veloci o no ?


a mio modesto parere:
la differenza di tempo (se esistesse) sarebbe talmente minima da non
giustificare la perdita di leggibilità.
Ho provato con la gettickcount e fino a 40 casi non viene rilevata alcuna
differenza,
in entrambi i casi 0 millisecondi.
Io comunque credo che la select case
sia più veloce primo perchè è  una sola istruzione e poi perchè legge la
variabile una sola volta.
P.S. e se ad un certo punto ti servisse un else?
--
----------------------------------------------------------------------------
Esiste un luogo dove tecnologia e arte si incontrano
www.tecnologiaEarte.net
----------------------------------------------------------------------------
Gianluca Pisano
ciao.

IF.
Sei sicuro?
C'è una bella differenza nel comportamento che pare nessuno abbia notato.
Il SELECT CASE *si ferma* al primo Case che soddisfa la condizione e non
esegue i successivi!
In realtà la struttura di confronto sarebbe un
If (condizione) then
elseif (condizione) then
elseif (...
end if
Infatti la regola per i Case è di mettere in alto (se possibili) i casi più
probabili.
Ciao

 probabili.
La regola è valida per qualunque routine di condizione :-D
Ciao
                   Pixel

l'applicazione deve elaborare i dati in arrivo da 10 server IRC e di
Scusa, ma visto il tipo di applicazione le prestazioni e
l'ottimizzazione non contano assolutamente niente.
Se sei collegato a 10 server irc e su ognuno dei quali sei su,
diciamo, 4 o 5 canali, ti arriveranno, diciamo, 300 stringhe al
secondo. Se nei Select Case hai 15 possibilita' fanno 4.500 test al
secondo, che su un piii 500 sono una miseria.
E poi tra Select Case e If Then ElseIf ecc. ci sara' un 2% scarso di
differenza di prestazioni perche' non si possono fare grosse
ottimizzazioni di codice.
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-VI --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD
   On contrary of popular belief, Unix *IS* user friendly:
    it just appears to be selective who it is friend with

 Saluti.
ok..ok... ormai ho capito che tra If..Then e Select Case non c'è poi una
gran differenza
di velocità.
Comunque, tanto per chiudere il discorso, scrivo la logica del motore IRC
che ho fatto, così magari ti viene in mente un'ottimizzazione (che sarebbe
ben gradita :-D):
Dati dal server
         |
        V
cek della prima stringa utile
(quella che termina con vbcrlf, tanto per capirci)
         |
        V
split della stringa ---> Nick - IP - Comando - Testo
                                             |
                                            V
                                      Comando
                                             |------> se numerico (codice
RAW) allora case sul numero (circa 170 casi utili)
                                             |------> se testo (PRIVMSG,
NICK, TOPIC ecc..) allora case sulla parola (40 casi utili)
                                             |
                                            V
                                       ritorno al cek della stringa
                                             |
                                            se stringa = "" allora ritorna
al winsock (dati in arrivo dal server)
Come avrai notato le possibilità che ho nel programma NON sono 15 ma un po'
di più ed inoltre
intervallate da alcuni controlli che ne rallentano ulteriormente
l'elaborazione.
Inoltre (immagino ovviamente che tu conosca i protocolli IRC) se avvengono
degli eventi "pesanti nel canale"
c'è un ulteriore rallentamento dovuto al refresh delle situazioni.
Per eventi pesanti intendo ingresso di 100 cloni, Mass kik, ingresso-uscita
rapida di cloni ecc..
Tanto per intenderci il buon Mirc lavora benissimo, nel senso che gestisce
con un soffio qualunque cosa accada, ma siccome io non sono il programmatore
di Mirc (mi sto rendendo conto che forse non sono neanche un programmatore)
e mi baso esclusivamente su esperimenti ed una vecchia conoscenza di Basic
mi trovo in crisi a gestire con rapidità gli eventi.
Concludo riportandoti questo esempio:
P III 800 con W2k --ISDN -- 5 server -- 2 room x server -- ritardo di
visualizzazione dati room = 2-3 secondi
e non dipende dallo stato del server in quanto i dati venivano visualizzati
nella spy-status al momento dell'arrivo....poi si perdevono nella
rielaborazione.
Ah...dimenticavo.....c'è un'ulteriore routine che si incarica di convertire
i codici colore di Mirc per essere visualizzati dal
programma...ecco....Finito
Come vedi il programma è (per le mie capacità) complesso e di conseguenza le
ottimizzazioni le cerco come "oro-colato".
Ciao
                           Pixel

 writes:
p> Tanto per intenderci il buon Mirc lavora benissimo, nel senso che gestisce
p> con un soffio qualunque cosa accada, ma siccome io non sono il programmatore
I client IRC hanno  10 anni di sviluppo alle spalle e  Mirc ne fa uso,
non ti abbattere.
