• Non ci sono risultati.

Una volta chiarita la struttura del programma si è cercato di individuare le classi e i metodi Java con un’influenza maggiore sul tempo di esecuzione.

Per farlo sono stati utilizzati dei software Java Profiler, ovvero JProf e TPTP.

3.3.1 JProf

JProf è un software sviluppato da IBM che permette di ottenere diverse informazioni sull’esecuzione di un programma Java.

Nello specifico è in grado di raccogliere tutte le informazioni riguardanti le chiamate dei metodi e dei relativi tempi di esecuzione.

Questo software è stato utilizzato durante un’esecuzione tipica del programma Adempiere, che prevedeva azioni comuni come l’inserimento di un nuovo Business Partner, la ricerca di un prodotto, l’inserimento di un nuovo ordine ecc …

I risultati vengono poi inseriti in un semplice file di testo con l’elenco cronologico dei metodi chiamati. Questo output si è rivelato però molto difficile da esaminare e gestire, soprattutto considerando le dimensioni del programma Adempiere. Per questo motivo le successive analisi che richiedevano un maggior dettaglio sono state eseguite con un altro tool, ovvero TPTP.

3.3.2 Test and Performance Tools Platform (TPTP)

39

Eclipse propone un ambiente di sviluppo multi linguaggio e multi piattaforma, che ha un suo punto di forza nella possibilità di aumentare le funzionalità tramite plug-in. TPTP è infatti un plug-in che può essere installato sia scaricandolo individualmente dal sito del progetto che tramite un update manager interno alla piattaforma Eclipse. La versione di Eclipse utilizzata nei test è la 3.6, chiamata Helios, mentre la versione di TPTP è la 4.7.2. Esiste una versione più recente della piattaforma, chiamata Indigo, ma non supporta più TPTP, in quanto la 4.7.2 è l’ultima versione rilasciata prima della chiusura del progetto.

Dato l’utilizzo della versione 3.6 di Eclipse si è utilizzata la versione 6 di Java, in quanto l’ultima versione 7 non viene supportata.

Il tool TPTP permette di raccogliere informazioni importanti sull’esecuzione di un programma java lanciato direttamente da Eclipse. In particolare vengono registrati per ogni metodo:

 Base Time: tempo di esecuzione netto del metodo, tenendo conto di tutte le volte che questo viene chiamato;

 Average Base Time: tempo medio di esecuzione del metodo, calcolato come Base Time diviso il numero di chiamate del metodo;

 Cumulative Time: simile al Base Time, ma considera anche il tempo di esecuzione dei vari metodi che possono essere chiamati. Coincide praticamente con il tempo intercorso tra la chiamata e la conclusione del metodo, comprendendo tutto quello che viene fatto all’interno;

 Cumulative CPU Time: tempo durante il quale la CPU è occupata nell’esecuzione del metodo;

 Calls: numero di chiamate del metodo.

Questi valori sono poi consultabili raggruppati per classe e per package. Vengono inoltre forniti tutti i dati come percentuale rispetto al tempo totale di esecuzione.

40

Una caratteristica molto utile è la possibilità di applicare dei filtri in modo da eliminare dall’analisi determinati metodi, classi o package che non vengono ritenuti interessanti.

Questo tool ha permesso di eseguire direttamente in Eclipse il programma Adempiere e tutti i casi test ed avere direttamente i dati sulle esecuzioni, senza bisogno di ulteriori programmi esterni. È possibile poi esportare tali dati in report in formato tabulare csv o html.

41

3.3.3 Scelta metodi per i test

Utilizzando questo tool per monitorare l’esecuzione di Adempiere si è riusciti ad elaborare una piccola lista con i metodi che hanno un impatto maggiore sui tempi di esecuzione del programma (Tabella 3.19).

Tabella 3.19 - Elenco metodi più significativi

Package Classe Metodo

org.compiere.model PO load()

org.compiere.model PO saveNew()

org.compiere.model GridTable getField(string) org.compiere.model GridField getColumnName() org.compiere.model GridTab loadField()

org.compiere.grid GridController Init()

org.compiere.util Env getCtx()

org.compiere.util DB prepareStatement(String,String) org.compiere.util Secure decrypt(String)

org.compiere.dbPort Convert_PostgreSQL convertCast(String) org.compiere.dbPort Convert convertStatement()

Dopo aver ottenuto una lista dei metodi più significativi si è passati ad analizzare il codice, in modo da trovare alcuni punti migliorabili.

Ci si è concentrati principalmente solo su alcuni tipi di costrutti e oggetti, come le stringhe e cicli.

Questa analisi manuale ha portato a galla alcuni blocchi di codice che si pensava poco efficienti e che sono stati oggetto di studio per elaborare migliorie energetiche. Il metodo che ha dato particolari spunti è stato il metodo load, metodo che carica i dati presenti in oggetti che rappresentano le colonne di un database. In questo metodo è stato trovato per esempio un blocco di codice costituito da una serie di if concatenati fra loro. La cosa è assolutamente lecita, ma nella fattispecie erano

42

abbastanza numerosi. Si è pensato quindi subito ad un modo per poterlo rendere più efficiente, come per esempio sostituirlo con uno switch.

In altri punti sono stati trovati numerosi cicli for che operano su oggetti particolari. Si è pensato quindi che l’introduzione di un iteratore potesse migliorare le prestazioni. Il metodo Convert ha invece offerto molti spunti per quanto riguarda la manipolazione delle stringhe. Infatti questo metodo effettua delle conversioni di statement in linguaggio SQL, effettuando normali operazioni come creazioni di sottostringhe, comparazioni ecc … Questo tipo di operazioni tipicamente non hanno un grande impatto sui tempi di esecuzione, ma dato che possono essere impiegate molte volte perché di uso comune, anche un piccolo miglioramento potrebbe dar un contributo significativo globalmente.

Verranno successivamente discussi i dettagli dei costrutti in esame e delle possibili migliorie.

Documenti correlati