Una delle fisse (una delle tante) che ci ritroviamo come programmatori è quella dell'ottimizzazione.
Come ogni fissa, sono diverse le scuole di pensiero: c'è chi ritiene di dover scrivere tutto in C o meglio ancora in assembler, chi ritiene si debbano evitare i linguaggi di scripting puramente interpretati a vantaggio di quelli basati su bytecode, chi di dover evitare questo o quel framework e che sia meglio riscriversi le funzionalità da zero invece che affidarsi a libreria di uso più generico... etc. etc. etc.
Ma il problema IMHO è che l'ottimizzazione è un problema che trascende il linguaggio di programmazione, il sistema operativo, la virtual machine, il framework e qualsiasi altra discriminante tecnologica.
Tra le cose lette e la mia modesta esperienza a riguardo credo di poter affermare di essere pienamente daccordo con Martin Fowler (http://martinfowler.com/ieeeSoftware/yetOptimization.pdf):
La prima domanda che ci dovremmo porre e a cui dovremmo dare risposta (alla Marzulliana maniera) è:
Ottimizzare COSA?!?!?
Inutile ottimizzare un software che non è stato ancora scritto
Inutile ottimizzare qualcosa che non si è ancora misurato... anche perchè se non lo abbiamo misurato... come facciamo a essere sicuri che quella che abbiamo intavolato è una ottimizzazione?
"If you make an optimization and don’t measure to confirm the performance increase, all you know for certain is that you’ve made your code harder to read." (Martin Flowler)
Quindi? Personalmente seguo gli insegnamenti di Obi-Wan :-)
"Use the Profiler, Luke"
Ultimamente mi sono trovato insieme ai miei altri Alca-compagni nella situazione di voler identificare quale parte di una nostra applicazione Javascript introduce un ritardo non proprio trascurabile per valutare se e cosa ottimizzare.
Le soluzioni che abbiamo trovato e provato per Javascript sono 3: Il primo si è rivelato molto efficace per effettuare il profiling del codice javascript privilegiato (quello nella zona chrome di mozilla):
Il secondo si è rivelato più comodo per il profiling di codice javascript contenuto nelle pagine HTML (quello nella zona content nella terminologia mozilla):
L'ultimo di è rivelato utile per misurare velocemente il profiling di una singola funzione o di punti particolari di una stessa funzione Javascript:
Provare per credere ;-)
"Use the Profiler, Luke... Use the Profiler"
Come ogni fissa, sono diverse le scuole di pensiero: c'è chi ritiene di dover scrivere tutto in C o meglio ancora in assembler, chi ritiene si debbano evitare i linguaggi di scripting puramente interpretati a vantaggio di quelli basati su bytecode, chi di dover evitare questo o quel framework e che sia meglio riscriversi le funzionalità da zero invece che affidarsi a libreria di uso più generico... etc. etc. etc.
Ma il problema IMHO è che l'ottimizzazione è un problema che trascende il linguaggio di programmazione, il sistema operativo, la virtual machine, il framework e qualsiasi altra discriminante tecnologica.
Tra le cose lette e la mia modesta esperienza a riguardo credo di poter affermare di essere pienamente daccordo con Martin Fowler (http://martinfowler.com/ieeeSoftware/yetOptimization.pdf):
La prima domanda che ci dovremmo porre e a cui dovremmo dare risposta (alla Marzulliana maniera) è:
Ottimizzare COSA?!?!?
Inutile ottimizzare un software che non è stato ancora scritto
Inutile ottimizzare qualcosa che non si è ancora misurato... anche perchè se non lo abbiamo misurato... come facciamo a essere sicuri che quella che abbiamo intavolato è una ottimizzazione?
"If you make an optimization and don’t measure to confirm the performance increase, all you know for certain is that you’ve made your code harder to read." (Martin Flowler)
Quindi? Personalmente seguo gli insegnamenti di Obi-Wan :-)
"Use the Profiler, Luke"
Ultimamente mi sono trovato insieme ai miei altri Alca-compagni nella situazione di voler identificare quale parte di una nostra applicazione Javascript introduce un ritardo non proprio trascurabile per valutare se e cosa ottimizzare.
Le soluzioni che abbiamo trovato e provato per Javascript sono 3: Il primo si è rivelato molto efficace per effettuare il profiling del codice javascript privilegiato (quello nella zona chrome di mozilla):
Il secondo si è rivelato più comodo per il profiling di codice javascript contenuto nelle pagine HTML (quello nella zona content nella terminologia mozilla):
L'ultimo di è rivelato utile per misurare velocemente il profiling di una singola funzione o di punti particolari di una stessa funzione Javascript:
Provare per credere ;-)
"Use the Profiler, Luke... Use the Profiler"
0 commenti:
Posta un commento