melixo ha scritto:
Sapere se ad esempio in determinati contesti è più veloce un for o un foreach, a prescindere dalla velocità di esecuzione che quella può dipendere da tante cose anche di un determinato momento.
Quando si parla di cosa è più veloce, in genere ci si riferisce alla velocità di esecuzione, perché altre velocità direi che non ce ne sono.
Detto questo, misurare la differente velocità tra un
for e un
foreach in un contesto come quello del linguaggio PHP, per giunta interpretato, è come prefiggersi di avviare uno studio serio e approfondito, con tutti gli strumenti specifici del caso, sul sesso effettivo degli angeli.
melixo ha scritto:
Sarebbe inutile quindi fare una differenza di timestamp, che tanto varia sempre.
Questa frase è un po' ambigua. Un "timestamp" se rappresenta la data/ora corrente, varia per forza, a meno che tu non abbia trovato il modo di fermare il tempo. Per calcolare una tempistica di esecuzione è più che adatto: sebbene non preciso, qualora si scenda sotto una certa soglia di misurabilità, significa che quel tempo di esecuzione potrebbe anche essere considerato identico.
melixo ha scritto:
Uno strumento più empirico, che calcola utilizzo della memoria, delle risorse.
Questo strumento appartiene alla categoria dei cosiddetti
profiler, tool che sono in grado di monitorare l'esecuzione del programma acquisendo degli "snapshot", tipo fotografie istantanee in sequenza, allo scopo di produrre una documentazione relativa a metriche specifiche di vario tipo, ad esempio l'elenco delle funzioni invocate, i tempi di esecuzione rilevati per ciascuna, il numero di oggetti allocati e poi deallocati (le garbage collection), l'uso della CPU, l'uso dei canali di I/O (es. da rete o da disco) e così via.
In genere, sono strumenti che si usano per risolvere un problema specifico rilevato sull'applicazione, anche perché non sono a "costo zero", e non mi riferisco a termini economici: per poter funzionare, devo inserirsi nel processo di esecuzione allo scopo di monitorarlo, quindi aggiungono dell'overhead, del "peso" aggiuntivo all'esecuzione (a volte rallentandola) ma con il benefit di raccogliere informazioni utili sul processo seguendo una configurazione fatta dallo sviluppatore per individuare colli di bottiglia, funzioni onerose in termini di memoria, oppure dei "memory leak" (dove ammessi) e così via.
melixo ha scritto:
Un modo anche per capire quali sono le scelte migliori in base a ciò che bisogna fare, imparare a scrivere di meno e ottenere di più, massimizzare insomma...
I compilatori e gli interpreti che usiamo oggi non sono uguali a quelli del passato e spesso incorporano funzionalità di ottimizzazione del codice scritto dallo sviluppatore, facendosi carico di tradurre il sorgente in una versione il più possibile performante (anche in base allo stato della macchina, es. RAM disponibile) lasciando invece lo sviluppatore libero di scrivere il codice favorendo la leggibilità piuttosto che altri fattori che renderebbero la programmazione più difficile dal punto di vista sia della produttività sia della manutenibilità futura.
Ovviamente è un discorso che andrebbe affrontato singolarmente per ogni tool, ma in generale vi è questa tendenza.
melixo ha scritto:
Come si può fare? Mi incuriosisce molto l'argomento. Perché io magari riesco anche ad arrivare al risultato che voglio, ma vorrei anche imparare a capire come arrivarci in modi migliori e più veloci. E non intendo solo a livello di tempo di esecuzione.
I "modi migliori" andrebbero ricercati curandosi di scrivere codice leggibile, chiaro, comprensibile e aderente ai pattern consigliati, piuttosto che perseguire l'ottimizzazione massima dello stesso magari facendo un lavoro peggiore del compilatore evoluto, scrivendo codice che nasconde al compilatore/interprete stesso le proprie intenzioni impedendo quindi una ottimizzazione ben superiore a quella che potrebbe introdurre lo sviluppatore medio.
melixo ha scritto:
Per dire una banalità, stavo usando un ciclo for($x=0; $x<=count($a);$x++) e mi sono chiesto perché dovergli a ogni giro fargli calcolare count() quando invece mettere il risultato prima in una variabile e fare poi il for? E dal MIT questo è tutto!
La soluzione più rapida è memorizzare preventivamente il
count() in una variabile e usare quella nel ciclo, ma come detto sopra, è possibile che l'interprete - riconoscendo il pattern - lo implementi già a questo modo senza che lo sviluppatore debba farlo, ottimizzando il codice ottenuto dall'interpretazione del sorgente. E' una eventualità da non escludere.
Ciao!