Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /web/htdocs/www.request.to.it/home/frank/scripts/sb_display.php on line 60
La chimera dell'ottimizzazione 
martedì, maggio 23, 2006, 10:19 - Dev, Design
Partiamo dalla legge dell'ottimizzazione:
- non ottimizzare
- (solo per esperti) non ottimizzare ancora

Sono stato coinvolto nel processo di ottimizzazione alla disperata ricerca delle performance. Mettendo insieme tutti i pezzi non si andava oltre le 100cps (Call Per Second), mentre il concorrente dichiara 350cps, stesso profilo di test, hardware inferiore. E' ovvio a tutti che mai raggiungeremo quelle prestazioni, soprattutto perchè il pradigma e completamente diverso. L'application server del concorrente implementa le SIPServlet che sono sincrone, l'AS che usa StarSIP come stack SIP (quindi noi siamo solo di supporto) è completamente asincrone ed event-driven.

Non so come, ma sono diventato l'esperto di ottimizzazione del codice. Visto che sono un po' bastardo, i primi due tool che ho presentato sono stati
pmd e metrics che sembrano non centrare nulla con l'obiettivo. La mia idea è che non puoi pensare ad ottimizzare se non hai del codice quantomeno decente. Non nomino nemmeno test e design che sono concetti un po' lontani dalla cultura del "il più è che funzioni e vada forte"....

Con l'ausilio dei due tool ho scovato tre classine niente male dove c'erano le peggio cose:
- oggetti instanziati in cicli for
- String pippo = new String ("pippo");
- try/catch dentro a cicli
- classi enormi, metodi da 300 righe
Le tre classi offrivano tre metodi che erano i più chiamati su tutto il globo terraqueo:)

Solo dopo si può cominciare a profilare. Dopo aver provato
tptp, un sotto progetto di eclipse, siamo tornati a OptimizeIt. Devo dire ottimo prodotto. TPTP "ammazza" un po' la macchiano sotto profilatura, OptimizeIt la lascia un pochino più viva. Abbiamo scovato sullo stack 4/5 punti dove potevamo ottenere dei miglioramenti prestazionali. Pochi cambiamenti al codice, ma visto che è codice eseguito ad ogni messaggio, ovvero almeno 100 volte al secondo, capite come anche 1ms di guadagno possa essere importante.

Molte delle ottimizzazioni fatte potevano essere evitate con un po' di buon senso e migliore conoscenza della tecnologia. Molto del design non fatto poteva essere fatto anche senza conoscere Java :)

Il terzo aspetto di questo processo è il tuning della JVM: heap, garbage collector....
Alla fine le impostazioni sono solo relative alla dimensione dell'heap (-Xms), mentre per il gc meglio lasciar fare alla jvm 5.0 che si autoregola da sola meglio che con impostazioni fissate :)

Adesso un po' di link:
- JVM tuning per incremento performance
- scrivere codice ottimizzato

[ 41 commenti ] ( 5348 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 570 )
Evitare la complessità 
martedì, maggio 16, 2006, 10:53 - Dev, Design
Io non so per quale ragione, ma ai programmatori piace la complessità. Ne sono attratti, se riescono a fare una cosa complessa, pensano che sia bellissima.

Personalmente, e lo ribadisco ogni volta, sono stupido: nella complessità mi perdo. Se una classe implementa più di due interfacce... sono fottuto :)

Nella <grande compagnia telefonica> dove sono in consulenza il software su cui opero è frutto della stratificazione di anni di lavoro: è pieno legacy!. In questi due anni ne ho prese parti, le ho smontate, revisionate, semplificate. Di molte classi ne ho fatto uno spezzatino!

Una cose che mi piace è delegare. Come tutti, all'inizio della mia esperienza in OOP sono stato affascinato dalla ereditarietà, fortunatamente il mio tasso di stupidità mi ha frenato molto presto.

Io preferisco la composizione. Classi piccole che composte fanno il "tutto". Ogni componente fa poco e poi delega a qualcuno che, nel mio caso, è "sopra". Io sono su di una "pila" protocollare, quindi c'è quasi sempre un livello superiore.

Il cuore dell'applicativo, nella sua precedente versione, era una gerarchia di tre classi da 5000 righe ciascuna. E' facile comprendere che spesso nelle riunioni tecniche mi debba scontrare con una "cultura" lievemente diversa. Ogni volta devo combattere strenuamente per adottare la soluzione più semplice.

Ma poi, come è successo l'ultima volta, tutto ciò che abbiamo disegnato al mattino sulla lavagna è stato stravolto e complicato nel pomeriggio durante la redazione di un documento riassuntivo.

Ma ce la farò anche questa volta, ne sono certo. La complessità non vincerà!





[ 11 commenti ] ( 1522 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 511 )
Caro programmatore.... 
martedì, marzo 14, 2006, 09:58 - FromOldBlog, Refactoring, Dev, Design
In risposta ai post del mio amico Enrico sui diritti dei programmatori e sulle paure dei programmatori, ripropongo riveduto e corretto un post dal vecchio blog aziendale:

Caro programmatore, sia tu un junior alle prime armi o un senior di provata esperienza (?!?!?), è così difficile?

E' così difficile scrivere classi con meno di 50 metodi?

E' così difficile scrivere metodi con meno di 50 righe?

E' così difficile usare nomi di variabili comprensibili?

E' così difficile scrivere codice che sia almeno un po' object oriented?

E' così difficile imparare un po' i principi di design?

E' così difficile imparare un po' i patterns?

E' così difficile non reinventare tutto da zero ed usare google?

Se hai risposto sì a tutte le domande.... cambia lavoro, stronzo! Perché il tuo codice di merda finirà nelle mani di qualcuno, e se quel qualcuno sono io spera di essere lontano... molto lontano.


Questo per sottolineare che i programmatori hanno diritti, paure, ma anche doveri: nei confronti di loro stessi e nei confronti dei loro colleghi.

C'è sempre qualcuno pronto ad obiettare: "Basta che funzioni".
Questo è un punto importante. Partiamo dal presupposto che nessun codice è esente dai bachi, ed anche se lo fosse presto o tardi dovrà essere modificato per assecondare le richieste di qualcuno.

Se scrivo del codice orrendo, ma funzionante (ora :) ), alla scoperta del primo baco sarà quasi impossibile farci manutenzione. Idem per una modifica. Farò più in fretta a riscriverlo. E questo anche per chi ha prodotto materialmente quella montagna di escrementi che si ostina a chiamare codice funzionante.

Non è poi così difficile. Puoi partire con un METODONE, ma poi lo prendi e lo scomponi in metodi più piccoli, magari ogni metodo lo testi, ma non lo pretendo :). Mi basta avere metodi piccoli, variabili con un nome comprensibile, classi di lunghezza ragionevole che facciano poche cose, ma fatte bene. Voglio codice che parla, non commenti che sono romanzi! Ah, i commenti... il commento dice che il metodo fa "toma", il metodo in effetti fa "soma", ma entrambi sono errati, perchè quel metodo doveva fare "roma".....

Meglio del codice bacato, ma su cui è facile fare manutenzione, che del codice che oggi funziona, ma che domani andrà riscritto perchè incomprensibile.

Il bello del software, è che è soft: lo puoi modellare come fosse pongo, adattarlo alla nuova situazione, ma devi metterti nelle condizioni di poterlo fare.




[ 15 commenti ] ( 2297 visite )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 2186 )