Newsgroup: it.comp.www.php
Titolo: Incidenza dei commenti nelle performance

E' chiaro che i commenti rallentano l'esecuzione di uno script php, ma 
ciò dovrebbe essere vero solo se non ho un acceleratore.
 
Se non ho un acceleratore, ogni volta il parser dovrà rileggersi tutte 
le righe. Se ce l'ho, solo la prima volta avrò un rallentamento dovuto 
alla necessità di salvare i bytecode da qualche parte.
 
Quindi, nel caso di un acceleratore, i commenti probabilmente non 
vengono messi in cache e quindi sono ininfluenti.
 
Tutto questo perché sto litigando con il mio capo che strippa tutti i 
commenti dai sorgenti (e mette tutto il codice su una sola riga, più o 
meno).
 
Sto dicendo scemenze?
Devo cospargermi il capo di cenere?
Posso andargli a sputare in un occhio?


Che ne rallentino davvero l'esecuzione ne dubito fortemente, a meno che 
il server web sia un Intel 8086. Secondo me stiamo parlando di 
millisecondi di differenza (sempre che ci sia).
 
E' chiaro che se è il tuo capo non puoi andare a dirgli "guarda che Jax 
mi ha detto che i commenti non rallentano".
Prova a cercare qualche test e/o benchmark, solo così (e forse neanche 
così) si convincerà che sbaglia.
 
-- 
Jax


 
E anche concesso il risparmio di qualche ms in esecuzione (sempre contando che un battito palpebra e' circa 50/80 ms) perderai secoli nel caso poi qualcuno debba rimettere le mani al codice.
 
La situazione e' diversa se invece parliamo di JS(ma essendo nel NG di PHP ho dato per scontato che si parlasse di sorgente PHP) dove ha senso minifare (si dira' cosi'??) tutto perche' devi oltre che eseguire, scaricarem, cachare ecc
 
J.
 
 
 
 

 millisecondi di differenza (sempre che ci sia).
 
Corretto, ma io direi che parliamo di microsecondi, non di 
millisecondi. :)
 
PHP, oggi, viene precompilato prima dell'esecuzione, e il tutto avviene 
nel giro di pochi millisecondi (la compilazione completa).
Il parsing dei commenti e` molto ottimizzato. Su un processore a 1 GHz 
direi che impiega un paio di miliardesimi di secondo a carattere, piu` o 
meno.
 
Se non ci scrivi la divina commedia, nei commenti, vai tranquillo.
 
Siamo a livello di microottimizzazioni ancora meno importanti della 
differenza tra print e echo...
 
E comunque non rallentano l'esecuzione, ma solo la compilazione, quindi 
anche se li metti in un ciclo, quando il ciclo viene eseguito i commenti 
gia` non ci sono piu`.
 
Scrivere tutto il codice in una riga, poi, e` veramente stupido. Non 
trovo parole migliori.
Perfino scrivere l'html tutto su una riga e` stupido (come incidono 1000 
a-capo su un HTML di 100.000 caratteri? Con webserver che spesso 
addirittura gzippano il file prima di mandarlo in rete), figurarsi il PHP 
che nemmeno passa in rete.
 
Bye.

 meno).
 
"The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it 
yet."

 Posso andargli a sputare in un occhio?
 
Andrebbe cosparso di cenere il capo del capo.

 così) si convincerà che sbaglia.
 
Forse dico una stupidata, ma farlo un benchmark? prepari un ciclo che 
giri un migliaio di volte dove fa solo un echo e qualche centinaio di 
righe di commento, lo si esegue da uno script con o senza commento e si 
valuta quanto ci impiega.
 
Ok, vado a dormire :D
 
Ciao
-- 
MMM

 Posso andargli a sputare in un occhio?
 
Guarda c'è anche chi è convinto che strippare tutti gli spazi bianchi (quindi tutto il codice su una sola riga) serva a qualcosa.
 
Però, finchè non gli dimostri il contrario in termini assoluti (benchmark dopo benchmark, sperando che abbia l'apertura mentale di accettare la _sconfitta_), fai come si fa con il javascript: i sorgenti te li tieni indentati e commentati bene e voi lavorate su quelli, poi sui server di produzione usate le versioni compresse (immagino che il tuo capo usi un tool per strippare i commenti, non dirmi che lo fa a mano...)
 
In questo modo accontenti tutti, perdi solo la possibilità di poter editare al volo file sul server di produzione, ma è una cosa che se il progetto è un minimo complesso non la faresti comunque.


Il discorso è nato perché il "sito" che stavamo mettendo su era lento, e 
secondo il "capo" la causa sono i commenti.
Togliendo i commenti e riformattando il codice si è ottenuto un 
miglioramento, penso soprattutto perché la dimensione complessiva del 
progetto è diminuita di un 20% circa.
Quello che tu dici è corretto, ed in quel caso però l'influenza maggiore 
l'avrebbe il filesystem.
 

 (immagino che il tuo capo usi un tool per strippare i commenti, non dirmi che lo fa a mano...)
 
In realtà li scrive già strippati...
 

 l'avrebbe il filesystem.
 
Mi verrebbe da rispondere "effetto placebo".
Fai qualche benchmark SERIO (ovviamente di nascosto, non vorrei che 
scoprisse che stai tramando contro di lui...), che escluda TUTTI gli 
altri fattori però.
 
-- 
Jax


Io scommetto che alla prima necessità di modifica di quel codice, un 
singolo programmatore perde, per capire il codice, tutto il tempo 
guadagnato nell'ultimo anno dalla rimozione dei commenti. :)
 
Vi costava meno mettere un acceleratore sul server, SE fosse stato 
veramente quello il problema.
 
La mia idea e` che, molto probabilmente, istanziare un oggetto in meno vi 
avrebbe dato piu` o meno lo stesso boost prestazionale, e un indice al 
posto giusto nel DB probabilmente avrebbe guadagnato almeno 10 volte di 
piu`.
 
Bye.

 In realtà li scrive già strippati...
 
cioè li scrive senza commenti ;)
 
Mhà, se vuoi dormire tranquillo io farei la strada di avere i sorgenti commentati e il codice di produzione _pulito_, se anche ora lo convinci che i commenti non ne sono la causa la prima volta che un qualcosa diventa lento sicuramente si rigioca questa carta... alcune leggende metropolitane sono dure da sfatare, specialmente se (per motivi intrinsechi) ha avuto falsi positivi sul suo metodo

 secondo il "capo" la causa sono i commenti.
 
Cambia capo.
 
Qualsiasi futura modifica del codice costerà più tempo, sangue e soldi 
di quelli che si risparmiano ora. A meno che non continuate a lavorare 
con codice commentato e indentato e poi facciate una rimozione 
(possibilmente automatica) di commenti e spazi prima di metterlo in 
produzione.

 l'avrebbe il filesystem.
 
E perche'? le operazioni da fare sono identiche in entrambi gli 
script... non devi valutare il valore assoluto di tempo, ma la 
differenza tra i due.
Un bash che banalmente stampa la data attuale, esegue il primo script, 
ristampa la data, esegue il secondo script e stampa la data, 
possibilmente con almeno i centesimi di secondo.
 
Ciao
-- 
MMM

 io farei la strada di avere
 
E mentre farei tutto questo cercherei presto un'altra azienda...
 
Ciao
-- 
MMM

l'avrebbe il filesystem.
 
Allora se proprio siete in questa situazione, usa un encoder/optimizer -
ma pellamordiddìo non fare il minify dei tuoi sorgenti, che dopo mettere
le mani li' dentro diventa una tortura Khmer.
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?