Newsgroup: it.comp.lang.perl
Titolo: disposizione codice

esiste un reale beneficio in termini di velocità di esecuzione, nel disporre 
le istruzioni nel listato consecutivamente , in vece che consequezialmente ?
for($x;$x<10;$x++){
    blabla1;
    blabla2;
    blabla3;
}
invece che:
for($x;$x<10;$x++){blabla1;blabla2;blabla3;} 

Ciao, GhanaWay! Che stavi dicendo?

non cambia assolutamente niente.
potresti avere qualche rallentamento solo nel caso in cui, tra le
istruzioni, ci fossero mega e mega di spazi bianchi...
-- 
Firma in costruzione

 writes:

perl compila il sorgente in una rappresentazione interna, che elimina
gli spazi inutili (oltre che ottimizzare le espressioni e parecchie
altre cose). I due sorgenti diventano esattamente la stessa cosa, una
volta compilati. Il secondo potrebbe (ma non prenderlo per vero: fai
dei benchmark) essere leggermente piu` veloce da caricare (visto che
ci sono meno byte da prendere dal disco), ma se ti capita di notare
questa differenza, pre un verso o per l'altro, hai problemi ben piu`
grossi di cui occuparti.
-- 
  dakkar
  sono su PerlMonks.org, 
use.perl.org
, PAUSE/CPAN

come De crescenzo diceva: .... la domanda sorge spontanea.... in quanto, nei 
cicli annidati, nella scrittura per esteso, (utilizzo PerlBuilder che 
possiede una funzione di Strep in, che mi restituisce passo passo il valore 
delle variabili), ciascun ciclo viene eseguito proggressivamente. Nella 
forma "compatta" (tutti i cicli annidati su di una riga di codice), invece, 
il dubugger mi vede ed esegue la serie dei cicli, un sola volta (nei tempi 
di un singolo ciclo), e restituisce i valori dei cicli contemporaneamente !
<dak...@nautilus.blackbit.lan> ha scritto nel messaggio 
news:87slshh...@nautilus.blackbit.lan...


 di un singolo ciclo), e restituisce i valori dei cicli contemporaneamente !
Effetti collaterali del debugger: il front-end che usi chiede al
debugger di eseguire 'fino alla prossima riga di codice', per cui non
si accorge di quello che succede.
Fai la stessa prova col debugger 'liscio': perl -d /path/allo/script E
vedrai che il comando 's' (esegui 1 istruzione) ti mostra piu` volta
la stessa riga di codice, tanto quante sono le istruzioni da
eseguirci.


... mi fido di fronte a cotal esperienza e ti ringrazio delle spegazioni a
questo.... sofismo! non capisco perň come  Perl Builder, chiedendo al
debbuger : "esegui fino alla prox istruzione", rispetto all'attuale, possa
portare ad una sorta di "ricorsione" nella sintassi compatta, rispetto a
quella STD : nella sintassi standard, il prox step per es di un ciclo ..
for{
    ..$x++;
    ..
    }
,  il debug valuta la x fino a : $x attuale +1, fermando il debug a x+1
(cfr.).
Perche allora, dato presupposto che il ciclo possieda piů di due iterazioni,
nella sintassi compatta, cicla fino alla fine, sputando i valori cosi
calcolati ?!
Ti ringrazio ancora per le spiegazioni.
Conosci /ete altri debugger, con prognosi/diagnosi (Step in) delle variabili 
? (meglio se GPL)
<dak...@nautilus.blackbit.lan> ha scritto nel messaggio
news:87wthqm...@nautilus.blackbit.lan...


 calcolati ?!
Comincio ad avere dei grossi problemi a capire cosa dici...
Secondo la mia analisi (non uso PerlBuilder) lui dice al debugger
"esegui fino alla prossima *riga*", non "istruzione", da cui la differenza.
Come debugger puoi provare:
- quello integrato in perl (perl -d)
- ptkdb, con GUI in Tk
- Devel::ebug, che funziona sia in modo testo sia via web (usando Catalyst)
