Newsgroup: it.lavoro.professioni.webmaster
Titolo: Vorrei avere il codice su UNA linea sola

Per svariati motivi voglio guadagnare anche un solo millisecondo.
Non so come si chiama questo metodo... Vorrei prendere del codice html
+php che ho scritto ben leggibile, indentato e spaziato (uso Aptana e
Notepad++) e con "un colpo solo" trasformarlo in un unica riga di
testo. Non sarebbe male neanche se togliese i commenti...
C'è un plugin per Notepad++ (o per Aptana?)?
C'è un software (free) che lo fa?
Grazie

 testo. Non sarebbe male neanche se togliese i commenti...
Fa sorridere pensare di risparmiare cicli macchina eliminando 
spaziature, a capo e commenti dal codice sorgente. Il compilatore ci 
mette niente a saltarli. Impiega enormemente, enormemente di più, tutto 
il resto: lettura da disco, compilazione, esecuzione, apertura della 
connessione al database, output ecc.
Evita solo di avere codici sorgente con megabyte di commenti. Solo in 
questo caso potrebbe esserci un lieve ritardo, imputabile principalmente 
all'accesso al disco.

 sarebbe male neanche se togliese i commenti...
Installa una cache di precompilati (APC, xcache, ...) e attiva gzip 
(mod_deflate in apache) sul server.
Se ancora non basta, usa una cache anche per le pagine pregenerate 
(memcache, ...).
Solo quando hai finito queste cose inizia a pensare di ottimizzare spazi 
e a capo per migliorare le prestazioni, e ti conviene farlo server side, 
dopo che php ha generato l'html.
Bye.

testo. Non sarebbe male neanche se togliese i commenti...
Togliere i commenti e' l'unica cosa che ha veramente senso.
La "perdita di tempo" nel resto è dovuta a:
1) Tokenizzatore che deve parsare più simboli whitespace,
2) Tempo di trasferimento dal disco del server.
Il tokenizzatore su una macchina moderna in stato whitespace, trovando
un altro whitespace, lavora comodamente sui gigatoken/s, visto che tra
l'altro si lavora in cache L2 se non L1. Tre accessi alla memoria, sei
compare (IIRC dai tempi di PHP4; dubito sia cambiato molto). Per avere
un miglioramento misurabile, dovresti averne e via, di whitespace.
Il trasferimento dal disco al server, hai uno script di 10 Kb - quanti
whitespace potresti averci? 512? E' un settore sul disco. Tipicamente,
una pagina di filesystem sono 4K, otto settori contigui; qui, si', nel
caso peggiore (tre seek a farfalla sull'intero disco) puoi perdere una
ventina di millisecondi *SE* quello script sta venendo caricato per la
prima volta.
Ma questo si verifica solo se, da prima a dopo il dimagrimento, quello
script ti cala da un multiplo a un altro di 4K (Linux; per Windows, la
cosa e' complicata), e non succede nemmeno sempre perche', se il disco
e' deframmentato, i settori sono contigui e di seek non ne fai neanche
una.
Quindi, avendo concluso che quello che ti frega è il tempo di seek sul
disco, credo che di sistemi per "ridurne la dimensione" ce ne siano di
ben migliori che renderlo illeggibile strizzando via gli spazi.
(O in altre parole: dopo aver strizzato gli spazi a morte... scoprirai
che quel "miglioramento di prestazioni", e' troppo piccolo per poterlo
misurare[1]).
Per esempio, scindere PHP e HTML e accelerare HTML, CSS e JS in Apache
http://serverfault.com/questions/78469/apache-send-pre-packed-gziped-files
Installare lo Zend Optimizer - o Zend Server
http://www.zend.com/it/community/zend-server-ce
Studiare la legge di Amdahl ;-)
http://it.wikipedia.org/wiki/Legge_di_Amdahl
...non entro nel dettaglio di COSA faccia lo script... ma scommetterei
qualcosina che si puo' migliorarne le prestazioni ;-)
Leonardo e i suoi .02 EUR
[1] se il miglioramento e' rilevabile, vuol dire che lo script aveva a
    monte degli ENORMI problemi, tipo commenti di 200 K con la manpage
    dentro o l'SVN inline. La soluzione non è levare gli spazi, è fare
    pulito.
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

Ho letto le le risposte e qualcosa di ciò che dite ho già fatto... ma
in siti fatti da me su server "mio" ... dove ho anche ottimizzato
cache, expiration, gzip e (poco)altro.
In questo caso specifico invece il server non è in mia gestione e non
lo posso configurare. Il sito non è mio e non volevo mettermi a fare
troppo casino o perderci troppo tempo.
Avete ragione, questa miglioria è trascurabile rispetto a quello che
si potrebbe fare... ma ormai questa curiosità mi piacerebbe
togliermela. Più a livello di test/sfizio. Fosse anche solo per vedere
il tempo di esecuzione dello script cambiare di quasi niente...
Quindi vi chiedo se conoscete comunque un software o un plugin o
altro.

 altro
Boh, credo che qualsiasi obfuscator possa fare quello che chiedi, ma č 
veramente roba per chi ha un sacco di tempo da perdere. Credo che 
l'ottimizzazione della logica dell'applicazione possa fare molto di piů, 
se non altro in termini di eleganza del codice (con grande soddisfazione 
del dio dei programmatori).
-- 
Falco Stellare
falco.ste...@gmail.com
www.deepvoid.it
(Togli il TAPPO per l'email corretta)

 se non altro in termini di eleganza del codice
Sono d'accordo... lo dicevo anche nell'altro post.


Ma 7960 e 7120 che sono? Millisecondi?
Se si, c'è qualcosa che non mi torna. Hai un guadagno di 0,8 secondi che 
non è pochissimo, ma un'enormità per il tipo di intervento fatto.
Se non puoi toccare il server, prova a installare smartoptimizer. Non è 
invasivo (a livello di codice) e spesso fornisce buoni risultati anche 
senza altri interventi.

 altro.
http://code.google.com/intl/it/speed/articles/optimizing-php.html
Io invece sto cercando un modo per velocizzare fpdf ! :-(
per un pdf con 170 pagine e una ottantina di foto ci mette 68 secondi 
sul server di test (9mb di output)
dati CPU Intel(R) Pentium(R) 4 CPU 2.80GHz
Su uno Xeon quad non so cosa potrei ottenere...
pareri ?
mi fare piacere scendere almeno sotto i 20 secondi...

pareri ?
**Se** sei nella situazione descritta in questo post
 
http://groups.google.com/group/it.comp.www.php/msg/3eddb94b35bb8d0d
FORSE ci posso fare qualcosa. Io avevo il problema di generare PDF da
80-300 Mb, senza fare aspettare ore l'utente né suicidare il server.
Alla fine ho maciullato fpdf e ho ottenuto quel che mi serviva, e, se
posso dirlo, con risultati... be'. Buonini, buonini :-D
Il problema sta nel fatto che (come quasi sempre mi capita) io non ho
messo su un "prodotto" clicca-installa-e-vai ma una serie di hack che
andrebbero (come minimo) rivisti.
Ad avere tempo contiguo mi coordinerei con Olivier per una release di
fpdf aggiornata :-(
(Se qualcuno inventa un deframmentatore di ritagli di tempo mi faccia
lui il prezzo - denaro, in natura, anima immortale, 'ndove firmo?)
Leonardo


 Su uno Xeon quad non so cosa potrei ottenere...
Essendo in puro PHP viene comunque eseguita sul singolo processo PHP, 
quindi puoi avere anche 128 core, ma un file verra` generato su uno solo 
di loro, e tutti gli altri stanno a guardare.
Non sapendo cosa e come faccia il tuo script, e` difficile darti 
consigli, ma se e` gia` ottimizzato, l'unica e` andare verso una libreria 
binaria (pdflib o simile), oppure, se possibile, forkare il lavoro e dare 
da fare una pagina per ogni processo, e poi ricostruirle alla fine. Devi 
implementarti un tuo "scheduler". A quel punto sfrutterai tutti i core, e 
anche un po' di hyperthreading, probabilmente.
Bye.


Se esiste un gruppo d'acquisto per l'oggetto partecipo subito.

 di loro, e tutti gli altri stanno a guardare.
beh però potrei gestire fino a 4 utenti in contemporanea che chiedono la 
generazione del pdf senza piantare il server giusto ?
spezzettare il pdf non ha senso in quanto ho visto che il tempo per 
pagina diminuisce all'aumentare delle dimensione delle pagine.
come già detto prevedo che nell'80% dei casi la generazione del pdf sarà 
inferiore a 10 pagine e quindi inferiore a 4-5 secondi che è del tutto 
accettabile.
Il problema si pone nell'altro 20% dei casi ;-) Spero solo che andando 
di forza bruta con un bel processore si recuperi qualcosa :-D
la cpu di test è uscita sul mercato nel 2002.
Qualcosa deve pur essere migliorato a parità di frequenza !

 senza altri interventi.
Ho guardato il sito, ma sembrerebbe morto come progetto, l'ultima 
versione beta e' di dicembre 2008, era questo che intendevi:
http://farhadi.ir/works/smartoptimizer
 ?
Ciao
-- 
MMM

secondi
Vedi anche dov'e' *esattamente* che perdi tempo - leggere i dati, farne
il parsing, chiamare fpdf, inviarli...?
Di norma io uso funzioni tipo
	function lap($message)
	{
		GLOBAL	$lapfp;
		if (!isset($lapfp))
			$lapfp = fopen(LOGFILE, 'a');
		fwrite($lapfp, microtime() . $message . "\n");
	}
e poi metto roba tipo,
	lap('inizio query 1');
	$exec = SQLExec(...);
	lap('inizio parsing risultati');
	...


 il parsing, chiamare fpdf, inviarli...?
a naso direi che è FPDF anche perchè è abbastanza lineare il tempo di 
realizzazione.
gli ultimi esempi:
3 pagine -> 1,49 secondi
9 pagine -> 2,56
20 pagine -> 6,57
23 pagine -> 8,24
28 pagine -> 11,10
161 pagine -> 64,59
Sino ad oggi mi sono concentrato su output, layout e sicurezza delle 
variabili... I benchmark saranno materia per i prossimi giorni.
ho fatto cmq attenzione a togliere dal loop tutto quello che non serve..
ed ho messo un bel LIMIT 30 sulle query di sql effettuate dal pubblico ;-)
dopo il weekend vi farò sapere cosa ho combinato ;-)

 	$exec = SQLExec(...);
O magari chiamare una funzione apposita invece di eseguire direttamente 
la query. Questa funzione si occuperà di controllare una variabile 
globale e in caso positivo si occupi di loggare ora munuti secondi 
centesimi di secondo di inizio della query, il testo della query e ora 
munuti secondi centesimi di secondo di fine della query.
Tecnica molto usata perché sapere quanto durano le query è una necessità 
ricorrente.

trovare i pacchetti che andranno impaginati nel pdf
Um. Potresti quindi preparare anticipatamente tutti i pezzi del pdf e
creare il superpdf usando pdftk, per esempio. Cioe' una cosa del tipo
{
	// Mi serve il PDF del pacchetto con ID 1723
	if (!is_up_to_date("cache/pacchetto-$ID.pdf"))
	{
		// Genero il pacchetto con makepdf
	}
}
// Creo il comando per pdftk e lo lancio
...
Questo ti taglierebbe fuori la grande parte del tempo di elaborazione
di fpdf. Idealmente, tutto.
E penso (ma č piů complesso, e non poco) che si possa modificare fpdf
per creare dei "pre-pdf parziali premasticati", da inserire con tempi
molto piu' ridotti.


 Ma 7960 e 7120 che sono? Millisecondi?
Secondo me si riferisce al numero di caratteri nel file prima e dopo la 
cura.


Ciao, intendo quello.
Morto o non morto il suo lavoro lo fa egregiamente e se non vengono 
segnalati errori o richieste...
A Dicembre 2008 avevo segnalato che c'era un problema con i files htc e 
dopo qualche giorno è uscito il bugfix.


Questa è una genialata !
L'unica cosa è che andrei a perdere il numero di pagine nel footer.

 L'unica cosa è che andrei a perdere il numero di pagine nel footer.
Non c'è modo di modificare un PDF già creato numerando le pagine?

L'unica cosa č che andrei a perdere il numero di pagine nel footer.
Se giochi pulito, sě (io non lo faccio mai: credo nuoccia alla salute).
Una delle cose carine di fpdf č che manda in output del testo buono. Tu
dirai, non lo fanno tutti? No, accidenti a loro. Ma fpdf sě.
Se prendi un PDF generato dalla FPDF, per esempio
 
http://www.fpdf.org/en/script/ex12.pdf
e gli fai
	pdftk ex12.pdf output ex12u.pdf uncompress
scopri che dentro cose come "Page 1/5" sono in chiaro, modificabili :-)
In teoria, fatte salve le immagini, il file ex12u.pdf potresti mandarlo
in output direttamente da PHP verso il pdf temporaneo da ricomprimere.
Comunque di sicuro puoi sostituire, in generazione, il numero di pagina
con - che so - PAGENUMBER e il numero totale di pagine con TOTALPAGES -
dopotutto il footer adesso lo fai tu, no?
A questo punto, per ogni pacchetto sai il numero di pagine (lo salvi da
qualche parte):
	TOTP = 0
	Ciclo Pacchetti {{{
		Trovato pacchetto NNN
		Esiste, fresco, il file PDF relativo?
			No o non č fresco -> lo rigenero e salvo NP
			(uso anche pdftk per decomprimere il file)
		Sě, recupero il suo NP e lo sommo a TOTP
		Accodo il nome del PDF all'elenco di input
	}}}
	// Qui ho un elenco di file PDF, e il numero TOTP.
	// Lancio pdftk e mi creo il superpdf, dove ogni pagina ha,
	// nel footer, "Pagina PAGENUMBER di TOTALPAGES. Il file e'
	// in chiaro, non compresso, e contiene TOTP pagine.
	// Salvo che se gli metto macari una copertina, questa *non
	// diventa* pagina 1, e questo mi va proprio bene.
	system "awk 'sub(/PAGENUMBER/,++c), sub(/TOTALPAGES/,25)' <
		pdf-12345-1.pdf > pdf-12345-2.pdf";
	// E ho un PDF ben fatto, con le pagine footerate numerate;
	// peccato sia non compresso, pero' adesso posso...:
	system "pdftk pdf-12345-2.pdf output pdf-12345.pdf compress"
	// Ed elimino pdf-12345-*.pdf, mi rimane solo il file buono
	// da mandar fuori con readfile()
Si possono fare giochi osceni con fpassthru(), cache, unlink, temporary
files per fare in modo che non restino file temporanei in giro.
