Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software

Transcript

1 POLITECNICO DI MILANO Scuola di Ingegneria dell'informazione Corso di Laurea Specialistica in Ingegneria Informatica Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Relatore: Prof.ssa Chiara FRANCALANCI Correlatori: Prof. Eugenio CAPRA Ing. Marco BESSI Tesi di Laurea di: Marco LUI, matricola Anno Accademico

2 Alla mia famiglia

3 Ringraziamenti Desidero in primo luogo ringraziare tutte le persone che mi hanno aiutato allo svolgimento di questo lavoro di tesi. Un sentito ringraziamento alla Prof.ssa Chiara Francalanci che mi ha dato l opportunità di svolgere questo lavoro molto interessante e per le utilissime (e divertenti!) lezioni dei suoi corsi. Un grandissimo ringraziamento anche al Prof. Eugenio Capra e all Ing. Marco Bessi per avermi costantemente seguito, aiutato e consigliato in tutto il lungo percorso della tesi. Rimanendo in ambito Politecnico vorrei ringraziare tutti i miei compagni di corso ed amici, in particolar modo Dario e Davide (mitticci!), che mi hanno accompagnato in tutta (o quasi tutta) questa avventura. E che belli i nostri progetti! Un ringraziamento a tutti gli amici, vicini e lontani che mi hanno supportato in questi anni e con cui ho passato momenti divertenti e spensierati. Un grazie speciale alle mie due famiglie, che mi hanno sempre sostenuto ed incoraggiato (e sfamato!). Infine un ringraziamento particolare a Jasmine, che mi ha costantemente incitato e rincuorato. Sei stata la stella che mi ha guidato! Grazie di tutto.

4 Abstract Nel corso degli ultimi anni i dispositivi tecnologici ed i sistemi informatici si sono molto sviluppati e diventati ormai di uso comune. Questa enorme crescita porta con sé anche alcune problematiche ambientali relative ai consumi energetici diretti ed indiretti (per esempio per gli impianti di condizionamento dei data center), con un conseguente impatto sull inquinamento terrestre. Per questo motivo è nata una nuova disciplina che si occupa di queste problematiche, ovvero il Green IT. Questo lavoro di tesi rientra nell ambito di un filone particolare del Green IT, ovvero il Green Software, che si occupa di massimizzare l efficienza energetica del software. Questo filone risulta ancora poco esplorato in quanto gli sforzi maggiori si sono concentrati soprattutto sul miglioramento dell efficienza dell hardware. Il lavoro di tesi si è concentrato sulla ricerca di regole metodologiche in grado di aumentare l efficienza energetica del software scritto in linguaggio Java. In particolare sono stati eseguiti diversi test riguardanti la gestione delle stringhe, l utilizzo degli iteratori e il costrutto switch. Sono stati creati dei piccoli programmi contenenti i costrutti obiettivo dell analisi e le loro versioni alternative, con l apporto di alcune modifiche. I test hanno permesso di confrontare i tempi di esecuzione di tutte le versioni e quindi di estrapolare alcune regole per la programmazione di applicativi Java in grado di massimizzare l efficienza energetica. Si è trovato ad esempio che l utilizzo di uno switch al posto di alcuni if concatenati fra loro (almeno 3) permette di risparmiare fino al 70% sul tempo di esecuzione. Oppure l utilizzo di un oggetto StringBuilder per il concatenamento tra stringhe permette di risparmiare il 50% rispetto al classico metodo con il simbolo +. 4

5 Le regole trovate non hanno un valore assoluto, ma dipendono sempre da alcune condizioni. Per esempio si è trovato che un iteratore che esamina gli oggetti contenuti in un vettore risulta più efficiente di un semplice ciclo (risparmio dal 15% al 65%), ma solo se il vettore contiene un certo numero di oggetti. Dato che un risparmio sul tempo di esecuzione non si traduce necessariamente in un risparmio energetico è stato necessario eseguire dei test energetici in laboratorio per la validazione delle regole. Come applicativo esempio è stato scelto Adempiere, un programma ERP Open Source. Sono stati ripetuti i test misurando il consumo energetico effettivo mediante un apposita strumentazione e questi hanno permesso di confermare la bontà delle regole trovate. I test energetici su un piccolo programma ad hoc implementato seguendo tutte le regole di ottimizzazione trovate ha permesso una riduzione del tempo di esecuzione del 65% ed un risparmio energetico vicino all 80%. 5

6 Indice Elenco delle Figure 9 Elenco delle Tabelle 11 1 Introduzione 13 2 Stato dell arte Introduzione al Green IT Green Software 22 3 Metodologia Introduzione alla metodologia Fase 1: Scelta ed analisi dell applicativo da testare Analisi programmi ERP Struttura di Adempiere Fase 2: Ricerca di classi e metodi significativi JProf Test and Performance Tools Platform (TPTP) Scelta metodi per i test Fase 3: Testing Test su if concatenati e switch Test sugli iteratori Test sulle stringhe: StringBuilder e StringBuffer Test sulle stringhe: substring 57 6

7 3.4.5 Test sulle stringhe: concatenamento Test sulle stringhe: metodi generici Test finale: programma ad hoc Fase 4: Analisi risultati e stesura regole Fase 5: Test energetici Strumentazione Preparazione ed esecuzione dei test 78 4 Risultati e regole di ottimizzazione Risultati test su if concatenati e switch If - switch a 7 scelte If - switch con meno di 7 scelte If - switch con più cicli Cicli for - while Risultati test sugli iteratori Iteratori con numero valutazioni variabili Risultati test sulle stringhe Metodo Convert Metodo Substring Metodo Substring con diverse dimensioni sottostringa Concatenamento di stringhe Concatenamento di stringhe con attributi statici Risultati test sui metodi generici Risultati test programma ad hoc Regole di ottimizzazione Validazione empirica dei risultati Validazione regole if - switch 113 7

8 5.2 Validazione programma ad hoc Stima risparmio energetico Stima risparmio energetico if - switch Stima risparmio energetico concatenamenti di stringhe Stima risparmio energetico sul test ad hoc Conclusione e sviluppi futuri Bibliografia 127 8

9 Elenco delle Figure Figura Andamento annuale dei costi delle infrastrutture IT. Fonte: IDC (2006) Figura Rapporto tra spesa per energia e raffreddamento / spese per nuovi server (%). Fonte: IDC (2006) Figura Diagramma Application Server Figura Diagramma Client Applicativo Figura Diagramma Gestione Database Figura Diagramma Interfaccia Grafica Figura Risultati di un'esecuzione esempio visualizzati con TPTP Figura Class Diagram del programma usato per il test su if concatenati Figura Gerarchia stringhe utilizzate nel metodo convert Figura System Board Figura NI USB-6210 DAQ Figura Interfaccia del programma di acquisizione dati in LabVIEW Figura Schema dei collegamenti del sistema di acquisizione dati Figura Grafico Base Time metodi load e load2 (a 7 scelte) Figura Grafico Cumulative Time metodi load e load2 (a 7 scelte) Figura Grafico andamento Base Time in base al numero di if / case Figura Grafico andamento Cumulative Time in base al numero di if / case Figura Grafico andamento Base Time in base al numero di POInfoColumn Figura Grafico Andamento Cumulative Time in base al numero di POInfoColumn Figura Grafico Base Time metodo load con e senza iteratori Figura Grafico Base Time metodo load con e senza iteratori (zoom) Figura Grafico Cumulative Time metodo load con e senza iteratori

10 Figura Grafico Cumulative Time metodo load con e senza iteratori (zoom).. 92 Figura Grafico Base Time metodi convert Figura Grafico Cumulative Time metodi convert Figura Grafico Base Time metodi sub Figura Grafico Cumulative Time metodi sub Figura Grafico Base Time metodi sub in base alla lunghezza sottostringa Figura Grafico Base Time solo primi 3 metodi sub in base alla lunghezza sottostringa Figura Grafico Cumulative Time metodi sub in base alla lunghezza sottostringa Figura Grafico Cumulative Time solo primi 3 metodi sub in base alla lunghezza sottostringa Figura Grafico Base Time metodi concatenamento stringhe Figura Grafico Cumulative Time metodi concatenamento stringhe Figura Grafico Base Time metodi concatenamento con attributi statici Figura Grafico Cumulative Time metodi concatenamento con attributi statici Figura Grafico Base Time metodo charat Figura Grafico Cumulative Time metodo charat Figura Grafico Base Time metodo getchars Figura Grafico Cumulative Time metodo getchars Figura Grafico Cumulative e CPU Time metodi load Figura Grafico Cumulative e CPU Time globali Figura Grafico tempo effettivo if/switch Figura Grafico energia effettiva if/switch Figura Grafico andamento Potenze istantanee nel tempo Figura Grafico tempo effettivo programma ad hoc Figura Grafico energia effettiva programma ad hoc Figura Grafico andamento Potenze istantanee nel tempo

11 Elenco delle Tabelle Tabella Packages contenuti nella cartella base/src Tabella Packages contenuti nella cartella glassfishfacet/src Tabella Packages contenuti nella cartella jbossfacet/src Tabella Packages contenuti nella cartella client/src Tabella Packages contenuti nella cartella sqlj/src Tabella Packages contenuti nella cartella install/src Tabella Packages contenuti nella cartella Extend/src Tabella Packages contenuti nella cartella serverroot/src/main/ejb Tabella Packages contenuti nella cartella serverroot/src/main/server Tabella Packages contenuti nella cartella serverroot/src/main/servlet Tabella Packages contenuti nella cartella serverapps/src/main/servlet Tabella Packages contenuti nella cartella zkwebui/web-inf/src Tabella Packages contenuti nella cartella JasperReports/src Tabella Packages contenuti nella cartella JasperReportsWebApp/src Tabella Packages contenuti nella cartella tools/src Tabella Packages contenuti nella cartella webcm/src/main/servlet Tabella Packages contenuti nella cartella migration/src Tabella Packages contenuti nella cartella posterita/posterita/src/main Tabella Elenco metodi più significativi Tabella Dati di esempio per il calcolo della confidenza Tabella Mappa valori tra ColumnClass e ClassInt Tabella Risultati test if - switch a 7 scelte Tabella Tempi di esecuzione metodi chiamati da load Tabella Tempi di esecuzione metodi chiamati da load Tabella Tempi di esecuzione if/switch con meno di 7 scelte Tabella Tempi di esecuzione in base al numero di POInfoColumn Tabella Tempi di esecuzione test for / while Tabella Tempi di esecuzione dei metodi con e senza iteratore

12 Tabella Tempi di esecuzione metodi convert Tabella Tempi di esecuzione metodi sub Tabella Tempi di esecuzione metodi sub in base alla lunghezza della sottostringa Tabella Tempi di esecuzione metodi concatenamento Tabella 4.12 Tempi di esecuzione metodi concatenamento con attributi statici Tabella Tempi di esecuzione metodo charat Tabella Tempi di esecuzione metodo getchars Tabella Tempi di esecuzione metodo load e loadmod Tabella Tempi di esecuzione MainAsIs e MainMod Tabella Riassunto regole di ottimizzazione energetica Tabella Dati test energetico su if/switch Tabella Dati test energetico programma ad hoc Tabella Risparmio if/switch nelle classi del package org.compiere.apps Tabella Risparmio if/switch nelle classi del package org.compiere.model Tabella Risparmi totali su if/switch Tabella Risparmio concatenamenti stringhe nelle classi del package org.compiere.apps Tabella Risparmio concatenamenti stringhe nelle classi del package org.compiere.model Tabella Risparmi totali sui concatenamenti Tabella Risparmio programma ad hoc Tabella Risparmio programma ad hoc con stima modificata

13 Capitolo 1 1 Introduzione Negli ultimi anni i sistemi IT si sono enormemente sviluppati e diffusi, con conseguente aumento della richiesta di energia per il loro mantenimento. Questa maggior richiesta di energia porta con sé ulteriori problematiche: Aumento considerevole del costo del mantenimento dei sistemi IT, dovuto anche al costante aumento del prezzo dell energia. Difficoltà nella scalabilità per i grandi sistemi, in quanto la fornitura di così grandi quantità di energia non sempre è possibile. Incremento dell impatto ambientale dovuto al consumo di energia. Queste problematiche hanno portato alla nascita e allo sviluppo di un nuovo campo di ricerca, il Green IT. Gli studi in questo nuovo campo si sono però principalmente concentrati sul miglioramento dell efficienza dei dispositivi hardware e sulla loro gestione logistica, mentre l aspetto software è stato preso poco in considerazione. In realtà anche il software può giocare una parte importante per il miglioramento energetico, in quanto gestisce e comanda l hardware. La maggior efficienza hardware potrebbe essere amplificata ulteriormente da un miglioramento della gestione dei dispositivi, soprattutto degli elementi più critici, come la CPU. Questo lavoro di tesi si pone all interno dell ambito ancora poco studiato dell efficienza energetica del software applicativo, cercando di fornire regole per la 13

14 Marco Lui Capitolo 1 - Introduzione programmazione energeticamente efficiente in linguaggio Java. Queste regole sono state validate in maniera sperimentale eseguendo delle misurazioni energetiche in laboratorio. I risultati ottenuti hanno confermato sperimentalmente la bontà delle regole elaborate. Nel Capitolo 2 vengono introdotti i concetti principali e le problematiche riguardanti il risparmio energetico. Viene descritto l impatto attuale e futuro del settore IT sia da un punto di vista ambientale che economico. Verrà illustrato infine lo stato attuale della ricerca sul software efficiente. Nel Capitolo 3 viene descritta la metodologia seguita per questo lavoro di tesi, mettendo in evidenza le varie fasi. Per ogni fase vengono descritti la procedura e gli strumenti utilizzati. Nel Capitolo 4 sono mostrati tutti i risultati ottenuti dai test su programmi esempio per la valutazione dei tempi di esecuzione di alcuni costrutti particolari e le possibili soluzioni per il miglioramento delle prestazioni. Verranno infine redatte alcune regole per la programmazione efficiente. Nel Capitolo 5 viene descritta la procedura sperimentale di validazione delle regole elaborate, effettuata tramite misurazioni energetiche (mediante un apposita strumentazione) di alcune esecuzioni di programmi ad hoc. Dai dati energetici si è potuto confermare l utilità delle regole di efficienza. Viene inoltre fornito un metodo per stimare il risparmio energetico prodotto dalle migliorie trovate. 14

15 Capitolo 2 2 Stato dell arte In questo capitolo viene descritto lo stato attuale della ricerca sul risparmio energetico nel campo dell Information Technology. Nel paragrafo 2.1 vengono introdotte le problematiche relative al Green IT, con la descrizione dei campi di studio e lo stato attuale della ricerca. Nel paragrafo 2.2 si prende in considerazione maggiormente un aspetto specifico, ovvero quello del Green Software, con le relative problematiche e gli sviluppi futuri. 2.1 Introduzione al Green IT I sistemi informatici ed i dispositivi tecnologici sono ormai diventati parte integrante della nostra vita. Data la loro enorme diffusione e l intenso utilizzo, questi sistemi hanno un impatto ambientale considerevole, che non può più essere ignorato. Secondo recenti studi [1, 2, 3] il settore IT produce il 2% delle emissioni globali di CO 2, con un impatto equivalente a quello dell industria aeronautica. Le previsioni per il 2020 indicano addirittura un aumento di questa quantità fino al 6% [2]. C è da notare però che l IT può avere un ruolo importantissimo nel monitorare ed ottimizzare il restante 98%, quello che viene chiamato IT for a greener business. I sistemi IT possono diventare fondamentali per il controllo di tutti i processi di business. 15

16 Marco Lui Capitolo 2 - Stato dell arte L impatto ambientale dell IT è costituito sia dai sistemi aziendali che dall IT distribuito, come per esempio PC, monitor, stampanti, laptop. Basti pensare che un singolo computer genera 1 tonnellata di CO 2 all anno [4] ed un Pentium IV dissipa 120 W, a fronte di soli 10 W di un 486. Questa richiesta di potenza si ha in quanto i processori si sono notevolmente evoluti, aumentando prestazioni e diminuendo le dimensioni, ma conseguentemente richiedendo più energia per la dissipazione del calore. I prodotti dell IT distribuito sono interessanti in quanto il loro campo di applicazione è molto vasto. Si parla infatti non solo dei prodotti acquistati da singoli privati, ma anche quelli utilizzati all interno degli uffici di qualsiasi azienda, società o pubblica amministrazione, ovvero qualsiasi luogo che dispone di postazioni di lavoro informatizzate. Nonostante ciò le leve principali che spingono verso l ottimizzazione sono più di tipo gestionale che informatico. Parlando invece di IT aziendale, ci si può fare un idea dei consumi energetici pensando che un moderno server blade consuma 1 kw, paragonabile al consumo di un normale frigorifero. Un rack di server blade (con 5 scaffali di 8 unità ciascuno) consuma 40 kw, cioè quanto una palazzina. Un data center di medie dimensioni può consumare anche 300 kw, l equivalente di 100 appartamenti, mentre grandi data center di grosse banche o di internet service provider possono consumare diversi MW, come un piccola cittadina. È quindi evidente che le riduzioni di consumo e di costo sono rilevanti, anche se riguardano un numero abbastanza ristretto di aziende (in Italia sono circa 3 mila i data center con più di 5 rack). [5, 6] La maggior parte del consumo di energia deriva dai componenti infrastrutturali, ovvero impianti di condizionamento, gli UPS (Uninterruptible Power Supply) e i sistemi di distribuzione dell energia. [7, 8] Come si vede in Figura 2.1, negli anni tra il 1996 ed il 2010 il costo dell hardware (in blu scuro) è cresciuto meno rispetto a quello dell energia e del raffreddamento (in verde). 16

17 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Figura Andamento annuale dei costi delle infrastrutture IT. Fonte: IDC (2006) Il costo di energia e raffreddamento rappresenta il 60% della spesa in nuove infrastrutture, come evidenziato nella Figura 2.2. C è da tenere in considerazione anche il fatto che questi valori sono ottenuti da analisi a livello mondiale, dove il costo dell energia è più basso rispetto all Italia (per esempio il costo dell energia a livello industriale è poco sotto i 7 $cent/kwh negli Stati Uniti, mentre in Italia è di quasi 26 $cent/kwh [9] ), ed evidenziano ancora di più l importanza di ridurre il consumo energetico nel nostro paese. 17

18 Marco Lui Capitolo 2 - Stato dell arte Figura Rapporto tra spesa per energia e raffreddamento / spese per nuovi server (%). Fonte: IDC (2006) La crescita considerevole dei consumi energetici dell IT sta attirando quindi l attenzione della comunità scientifica, dei produttori di tecnologia e dei responsabili del settore IT. Da queste basi sorge il Green IT, ovvero un informatica ecologicamente sostenibile. Il Green IT si occupa dello studio e dell attuazione di tecniche di progettazione e realizzazione di computer, server, sistemi connessi e sistemi di comunicazione efficienti, con impatti ambientali ridotti. [1] Le tematiche principali che studia possono essere riferite a queste tre: Miglioramento dell efficienza energetica dell IT. Gestione eco-compatibile del ciclo di vita di tutti gli apparati dell IT. Utilizzo dell IT come strumento di governance green. La prima area ha l obiettivo di migliorare la progettazione dell architettura dei sistemi informativi e dei data center, in modo da ottimizzare il consumo energetico. Vengono presi in considerazione diversi aspetti di questi ambiti, come la virtualizzazione, la scelta oculata dei server, il ripensamento del layout dei data center, l ottimizzazione degli impianti di condizionamento, ma agendo anche sulle abitudini di utilizzo e modificando la cultura aziendale. 18

19 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software La seconda area riguarda l impatto ambientale del ciclo di vita dei componenti IT ed il loro smaltimento. Vengono presi in considerazioni aspetti che vanno dalla produzione dell hardware limitando l uso di sostanze pericolose, all ottimizzazione degli imballaggi e alla rottamazione dei prodotti non più utilizzabili. I rifiuti di apparecchiature elettriche ed elettroniche (RAEE), chiamati anche Waste of Electric and Electronic Equipment (WEEE), o più semplicemente e-waste, sono rifiuti particolari derivanti da qualsiasi apparecchiatura elettrica od elettronica. Tali rifiuti contengono sostanze tossiche ed è quindi molto importante controllare la loro dismissione, in modo da non costituire pericolo per l ambiente. Secondo alcune recenti ricerche [3] il 70% dell inquinamento del suolo da piombo, cadmio e mercurio deriva direttamente o indirettamente dall IT. Sono quindi state introdotte diverse norme per la regolazione dello smaltimento di questi rifiuti in recepimento di alcune direttive Europee. [10] La terza area ha l obiettivo di utilizzare le tecnologie IT per il monitoraggio e la misurazione del grado di eco sostenibilità di ogni processo aziendale ed industriale, non quindi necessariamente connesso con l IT. Si parla per esempio di controllo sul consumo energetico, sulle temperature, sull utilizzo di materiali come carta ed accessori, sulla produzione di rifiuti tossici. Questo monitoraggio può essere effettuato definendo dei nuovi Key Performance Indicator (KPI) green portandoli all attenzione dei manager. I KPI possono essere memorizzati ed analizzati tramite cruscotti direzionali e di business intelligence. [5] Data la vastità del campo di ricerca del Green IT, l approccio sicuramente migliore per massimizzare l efficienza energetica (soprattutto per le aziende) è quello multilivello. È importante infatti agire contemporaneamente su diversi aspetti del sistema informatico e non solo su quello che incide di più sul consumo. Da un articolo di Francalanci e Capra [5] viene qui ripreso un esempio riguardante un data center: i livelli su cui si può agire sono numerosi. A livello di infrastruttura i punti più critici sono quelli dei gruppi di continuità ed i sistemi di condizionamento. Nel caso questi ultimi fossero a potenza fissa, si potrebbe pensare di sostituirli con altri in grado di modulare il raffreddamento a 19

20 Marco Lui Capitolo 2 - Stato dell arte seconda del luogo e delle necessità. Inoltre le disposizioni degli scaffali e delle bocchette di condizionamento dovrebbero essere studiati con cura. A livello di sistema si possono ottenere enormi risparmi bilanciando correttamente i carichi di lavoro sui server ed utilizzando la virtualizzazione. Analizzando i singoli server si possono trovare diversi punti critici, come la gestione delle periferiche e dei componenti ausiliari. Modulare la velocità delle ventole in base alle necessità è un esempio molto semplice e pratico per ridurre i consumi, oppure utilizzare meno drive ma più potenti. Questi accorgimenti possono portare a riduzioni fino al 50% dei consumi. Un altra grande fonte di spreco è la conversione dell energia da alternata a continua per ogni singolo server, che può essere ottimizzata centralizzandola in un unico dispositivo per più macchine. Questa soluzione richiede però che i macchinari siano predisposti e necessita di collaborazione da parte dei produttori hardware. Infine anche una migliore gestione della distribuzione dell energia ad alcune componenti del sistema, come la cache, può portare notevoli vantaggi, alimentando solo le parti in quel momento utilizzate. Un altro punto critico con notevoli inefficienze è il processore, ben lontano dalle massime prestazioni possibili. Spesso inoltre non funzionano al massimo delle loro capacità e non vengono sfruttati in maniera efficiente. L abbassamento della frequenza di clock e l utilizzo di più core possono ridurre i consumi fino al 50% [1]. A livello di rete si potrebbe ottenere una maggiore efficienza ripensando gli algoritmi di routing tenendo in considerazione anche gli aspetti energetici, oltre ad utilizzare hardware più efficiente. In un certo modo anche i database possono influenzare negativamente l efficienza energetica. Infatti se i dati sono di scarsa qualità (duplicati, non aggiornati, inconsistenti) richiedono più transazioni ed operazioni per la correzione ed il loro reperimento, aumentando quindi i consumi. Chiaramente anche il software gioca un ruolo fondamentale, ma verrà discusso nel dettaglio nel paragrafo successivo. 20

21 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Infine non si deve assolutamente trascurare che le pratiche di utilizzo possono essere causa di notevoli inefficienze. Alcune ricerche hanno dimostrato che un corretto uso delle funzioni di power management, l uso intelligente di screen saver e la buona abitudine di spegnere i sistemi quando non utilizzati, possono portare ad un risparmio del 60% dei consumi. [11] Oltre a queste vi sono numerose altre azioni da fare per ridurre gli sprechi, come per esempio effettuare stampe fronte-retro, riparmiando carta ed energia. In generale è necessario un cambiamento culturale aziendale e degli utenti. L intera azienda dovrebbe cominciare a tenere in considerazione l aspetto green nella progettazione, manutenzione e gestione di tutti i sistemi, sia per l aspetto ambientale, sia per l aspetto economica che ne deriva. A livello nazionale ed internazionale cominciano ad aumentare le iniziative e gli accordi per la progressiva diminuzione dei consumi energetici e dell inquinamento che ne deriva, proponendo anche incentivi per la ricerca ed il risparmio. La Comunità Europea ha sviluppato diverse normative volte ad incentivare il risparmio energetico, soprattutto in ambito industriale (direttive 2001/77/CE, 2005/32/CE, 2006/32/CE). [12] Come non citare inoltre il famoso protocollo di Kyoto sottostritto nel 1997 nell ambito della Convenzione quadro delle Nazioi Unite sui Cambiamenti Climatici (UNFCCC). Recentemente negli Stati Uniti sono stati varati pacchetti ecomici, noti come American Recovery and Reinvestment Act (ARRA), che riguardavano anche l efficienza energetica e la ricerca nelle energie rinnovabili (27.2 Miliardi di dollari). [13] 21

22 Marco Lui Capitolo 2 - Stato dell arte 2.2 Green Software I responsabili del consumo di energia sono fisicamente i dispositivi hardware, ma questi sono necessariamente guidati dal software, che è quindi il responsabile primo (non fisico) e che determina quali operazioni devono essere eseguite e come. Il Green Software è la disciplina che studia le modalità con cui il software influenza i consumi energetici dell IT, cercando nuovi modi per ottimizzarlo. [6] Questo aspetto di solito viene poco preso in considerazione, in quanto si pensa che il software abbia un influenza ridotta sui consumi, riconducibile solamente al processore, che di per sé non è la fonte principale di consumo. Infatti i maggiori sforzi fatti finora nell ambito del Green IT si sono concentrati sull hardware e sulle strutture. Questo però è un approccio limitato, in quanto se il software è più efficiente e riesce a svolgere le stesse funzioni con meno operazioni ed in meno tempo, si avranno vantaggi a cascata anche sulle altre componenti, in quanto sarà prodotto meno calore, con un calo del fabbisogno energetico per il condizionamento. Finora i principali studi di low power software si sono concentrati sui sistemi embedded. In questo caso però la leva principale non era il risparmio energetico rivolto ad un minor impatto ecologico, ma indirizzato alla limitazione di consumo della batteria, vero limite dei dispositivi mobili. In generale però il classico ciclo di sviluppo di un software non prende mai in considerazione l efficienza energetica come uno degli obiettivi, come invece lo sono costi, funzionalità e performance. Uno dei problemi principali che si trovano nell ambito dell ottimizzazione del software è sicuramente la ricerca di un metodo per misurare l efficienza energetica, soprattutto la definizione di una metrica. Infatti l efficienza va valutata come consumo in base alla quantità di lavoro svolta e quindi molto dipendente dalle condizioni del sistema e dal carico di lavoro. Oltretutto risulta anche difficile scorporare il consumo relativo al software dal consumo generale del sistema. L obiettivo di migliorare l efficienza energetica del software può essere raggiunto principalmente mediante due approcci. Un primo approccio è quello dell ottimizzazione a livello di sistema, indipendente quindi dal tipo di codice 22

23 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software utilizzato. La ricerca in questo campo è molto aperta e spesso si focalizza sulla scelta oculata dello stack, dato che l interazione tra sistema operativo e applicazione ha un impatto sul consumo considerevole. Il secondo approccio è quello invece relativo all ottimizzazione del codice. Chiaramente un codice ben scritto può avere notevole influenza sulle performance energetiche del programma. Ma questo approccio può portare ad ulteriori benefici, come lo sviluppo di metodologie, linee guida e tool per lo sviluppo di software efficiente. Il lavoro di questa tesi si pone proprio all interno di questo ambito, cercando di elaborare linee guida utili per lo sviluppo di software energeticamente efficiente. Non sempre però questo tipo di approccio è utilizzabile (in caso di software non prodotto in proprio) e utile: non è pensabile per esempio analizzare ed ottimizzare tutto il codice di un sistema bancario e se anche ci si riuscisse probabilmente lo sforzo difficilmente verrebbe ripagato dai risparmi ottenuti. 23

24 Capitolo 3 3 Metodologia 3.1 Introduzione alla metodologia In questo capitolo verrà mostrata la metodologia che è stata seguita per lo svolgimento del lavoro di tesi. Verranno descritte le diverse fasi, gli strumenti utilizzati e il metodo di analisi dei dati raccolti. Le fasi principali descritte in seguito possono essere così riassunte: 1. Scelta ed analisi dell applicativo da testare: sono elencati i programmi presi in considerazione e l analisi approfondita dell applicativo scelto. 2. Ricerca di classi e metodi significativi: sono descritti gli strumenti utilizzati per la ricerca delle classi e dei metodi con maggior impatto sui tempi di esecuzione. 3. Testing: sono descritti i test effettuati per la valutazione dei tempi di esecuzione dei programmi con e senza le modifiche per il miglioramento dell efficienza, suddivisi per categorie. 4. Analisi dei risultati: sono riportati i dati ottenuti nei test, con la loro analisi e la stesura di regole per la programmazione efficiente. 5. Test Energetici: sono descritti i test energetici effettuati per la validazione dei risultati ottenuti in precedenza, gli strumenti necessari per le rilevazioni energetiche e la metodologia utilizzata. 24

25 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 3.2 Fase 1: Scelta ed analisi dell applicativo da testare Analisi programmi ERP Per prima cosa è stato svolto un lavoro esplorativo sulle applicazioni disponibili e più adatte allo scopo. Come avvenuto in lavori precedenti, per esempio quello di Formenti e Gallazzi [14] e quello di Alberio e Brianza [15], sono stati analizzati alcuni programmi ERP (Enterprise Resource Planning). Questi programmi permettono di integrare i processi di business rilevanti per un azienda, come le vendite, gli acquisti, il marketing, la contabilità, la gestione magazzino ecc [16] Sono stati scelti questi programmi in quanto utilizzati nelle aziende, che potrebbero essere i soggetti più interessati ad un risparmio energetico, e quindi economico. La peculiarità di questi programmi è che sono tipicamente suddivisi in moduli, ognuno con le proprie funzionalità, ma in grado di comunicare con gli altri moduli. La scelta dei moduli dipende dalle esigenze e dalle caratteristiche dell azienda. Tra i componenti principali possiamo trovare: Contabilità Controllo di gestione Gestione del personale Gestione Acquisti Gestione dei magazzini Material Requirements Planning - Pianificazione del fabbisogno dei materiali. Gestione della produzione Gestione Progetti Gestione Vendite Gestione della Distribuzione Gestione della manutenzione impianti Gestione degli Asset [16] 25

26 Marco Lui Capitolo 3 - Metodologia L analisi si è concentrata però su prodotti dedicati ad aziende di medie-piccole dimensioni e che propongono una soluzione all-in-one, ovvero un solo programma con tutte le funzionalità più importanti. Sono stati analizzati 3 programmi ERP: Adempiere OpenBravo OpenERP La caratteristica comune a tutti è che sono programmi Open Source. Questa caratteristica si è resa fondamentale per poter esplorare senza problemi il codice sorgente ed esaminare a fondo struttura e funzionalità di questi programmi. Dopo aver analizzato questi programmi si è deciso di concentrarsi su Adempiere, in quanto è stato ritenuto più semplice da utilizzare ed adatto allo scopo. Il programma è scritto in linguaggio Java e permette di default l utilizzo del database PostgreSQL, anch esso Open Source. La versione a cui si farà sempre riferimento è la 3.6. Una volta scelto il programma ne è seguita un analisi statica, in modo da capirne la struttura e le funzionalità Struttura di Adempiere La struttura è abbastanza complessa; infatti il codice del programma è suddiviso in 19 package e più di classi Java. Vi è la possibilità di utilizzare il programma sia installando un client sul proprio PC che sfruttando l interfaccia web messa a disposizione. Nel secondo caso è necessario quindi un application server con cui fare il deploy dell applicazione. I comandi e le funzionalità sono comunque gli stessi in entrambe le modalità di funzionamento. Di default sono consentiti due Application Server differenti: JBoss e Glassfish. È possibile però aggiungere altri tipi di server implementando correttamente le interfacce corrispondenti. Nello specifico è presente un interfaccia IApplicationServer che rappresenta il generico Application Server. Le classi 26

27 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software specifiche di ogni tipologia di Server devono necessariamente implementare quell interfaccia. La classe ASFactory contiene un elenco aggiornato delle istanze di Application Server disponibili. Nel nostro caso però non è stato necessario utilizzare l interfaccia web e quindi si è preferito eseguire i test con un client applicativo installato su PC. Figura Diagramma Application Server Adempiere prevede la possibilità di un applicativo da installare sulla macchina client. La parte grafica viene gestita dalle classi contenute nei package org.compiere.apps (e apps.form, search e wf), org.compiere.grid, org.compiere.minigrid. 27

28 Marco Lui Capitolo 3 - Metodologia Figura Diagramma Client Applicativo Anche per quanto riguarda il Database di appoggio sono presenti in Adempiere due possibilità di default: PostgreSQL e Oracle. La scelta è ricaduta su PostegreSQL, un database Open Source. È sempre possibile comunque aggiungere la compatibilità con altri database implementando le interfacce che gestiscono i database. In questo caso è presente l interfaccia AdempiereDatabase che deve essere implementata dalle classi dei singoli DB, come DB_Oracle e DB_PostgeSQL. Esiste poi una classe Database che mantiene l elenco dei Database disponibili. Figura Diagramma Gestione Database 28

29 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Aggiungere il supporto ad un nuovo tipo di Database implica anche il fatto di dover implementare una classe che permetta la conversione dei comandi SQL standard nel linguaggio target del database, basandosi su una classe astratta Convert. I package che si occupano di definire la veste grafica del programma sono org.compiere.swing (che opera una ridefinizione delle classiche swing), org.ademiere.plaf (che gestisce il look&feel), org. compiere.plaf. Figura Diagramma Interfaccia Grafica L interfaccia grafica costituisce una parte decisamente importante per quanto riguarda i consumi ed il tempo di esecuzione. Questa incisività ha comportato diversi problemi nella fase di raccolta dei dati che verrà spiegata successivamente. Per completezza verrà riportato ora l elenco di tutti package che compongono il codice di Adempiere, con una breve descrizione di ognuno di essi. Tabella Packages contenuti nella cartella base/src Package com.akunagroup.uk.postcode org.adempiere.apps.graph org.adempiere.as Descrizione Contiene interfacce e classi per il servizio web di ricerca di codice postale. Si occupa della creazione e gestione dei grafici. Trova e restituisce l application server 29

30 Marco Lui Capitolo 3 - Metodologia installato (jboss o glassfish). org.adempiere.common Contiene una classe che inserisce in una mappa valore-chiave i nomi di alcune classi utilizzate nel client con le rispettive classi del client web. org.adempiere.exceptions Raccoglie tutte le classi che definiscono le eccezioni. org.adempiere.impexp Gestisce l esportazione di dati in file xls. org.adempiere.model Si occupa della gestione del modello (bean, tabelle, oggetti persistenti ). org.adempiere.pdf Genera report in formato pdf. org.adempiere.pdf.viewer Visualizzatore pdf che usa jpedal. org.adempiere.pipo Contiene interfaccia e classi per l import - export di file xml e conversioni in xml. org.adempiere.pipo.exception Contiene classi che estendono runtime exception. org.adempiere.pipo.handler Contiene tutte le classi che estendono o lavorano con le classi di pipo per la conversione xml. org.adempiere.plaf Gestione del look and feel. Vengono ridefiniti button, label, combo box ecc delle rispettive swing. org.adempiere.print.export Implementa l interfaccia per l esportazione in file xls in org.adempiere.impexp. org.adempiere.process Classi che estendono org.compiere.process.svrprocess. Generano campi ASP e gestiscono ordini RMA. org.adempiere.process.rpl Contiene un interfaccia per l import export e una classe di utility per XML. org.adempiere.process.rpl.exp Contiene classi per l esportazione. org.adempiere.process.rpl.imp Contiene classi per l importazione. org.adempiere.util Package che raccoglie classi che forniscono utility di vario genere. In particolare presenta classi che permettono di creare 30

31 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software org.compiere org.compiere.acct org.compiere.cm org.compiere.db org.compiere.dbport org.compiere.impexp org.compiere.interfaces org.compiere.model org.compiere.plaf org.compiere.print org.compiere.print.layout org.compiere.process nuovi modelli di classe e un interfaccia per effettuare ricerche di campi nel database. Contiene la classe Adempiere per lo startup del sistema. Gestione dei record pubblicati. Contiene una classe per il controllo del deploy del web project e qualche utility di gestione stringhe. Package per la gestione dei database. Contiene le classi per la conversione di comandi SQL da Oracle ad altri database. Contiene classi per l import di modelli e formati. Presenta l interfaccia per il server adempiere (executetask, dbprocess, create , workflow ) e per lo Stato del db (principalmente getter). Contiene diverse interfacce per le tabelle dei database. Queste interfacce vengono implementate dalle relative classi, le quali estendono la classe PO. Pluggable Look&Feel UI. Gestione stampa. Gestione stampa del layout. Fornisce i processi utilizzati a livello Server (e opzionalmente a livello Client). A runtime viene controllata la presenza del Server. Se esiste le classi vengono invocate via Application Server, altrimenti localmente. Sono presenti molte classi importanti, principalmente per: gestire account, adempiere server e service, allocazione processi, gestione BP, crittazione colonne, 31

32 Marco Lui Capitolo 3 - Metodologia copia oggetti, gestione ordini, colonne ecc org.compiere.report Contiene le classi dei modelli di report per colonne, linee, alberi e report finanziari. org.compiere.report.core Contiene le classi per creare i report. org.compiere.sla Criteri, misurazioni e Goal del Service Level Agreement. org.compiere.swing Fornisce le componenti swing per l interfaccia di Adempiere. org.compiere.tools Fornisce utility per i file (processamento, sostituzione stringhe, latex), testing RMI e conversione file testo Windows in Linux. org.compiere.util Package che contiene diverse utility, come la gestione degli errori di configurazione, traduzione di numeri in parole nelle varie lingue, processi asincroni, gestione cache, gestione logger, gestione DB, gestione System Enviroment, traduzioni del login, gestione login, Sicurezza. org.compiere.wf Modelli di workflow e loro gestione. org.eevolution.model Contiene numerose interfacce generate e modelli generati che le implementano. org.eevolution.process Contiene qualche classe per il trasferimento bancario, creazione di formati di esportazione da una finestra, calcolo tasse sugli ordini. org.globalqss.process Permette di creare report del Cash Flow e la gestione del Cash Plan. Tabella Packages contenuti nella cartella glassfishfacet/src Package org.adempiere.as.glassfish Descrizione Contiene la classe Glassfish che implementa org.adempiere.as.iapplicationserver (in base/src) e un modulo per la login. 32

33 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Tabella Packages contenuti nella cartella jbossfacet/src Package org.adempiere.as.jboss Descrizione Contiene la classe JBoss che implementa org.adempiere.as.iapplicationserver (in base/src) e un modulo per la login. Tabella Packages contenuti nella cartella client/src Package Descrizione de.schaeffer.compiere.tools Contiene una classe che implementa l interfaccia AbstractDocumentSearch in org.adempiere.util (base/src) per la ricerca e l apertura di finestre per transazioni definite. org.adempiere.apps.graph Contiene classi per la gestione dei grafici e le relative utility, lato client, e la visualizzazione degli Indicatori di Performance. org.compiere.acct Gestione Account Viewer e relativi dati. org.compiere.apps Contiene classi che implementano componenti dell interfaccia utente di alto livello del client applicativo. Per esempio il menù delle finestre. Contiene anche le conversioni nelle varie lingue del login. Permette anche di allegare file. org.compiere.apps.form Raccoglie modelli di form personalizzati. org.compiere.apps.search Classi che implementano la ricerca, visualizzazione info, lookup. La ricerca viene effettuata su diversi oggetti: operazioni cash, asset, BP, Ordini, Invoice org.compiere.apps.wf Classi per l interfaccia utente del workflow (layout, pannello, icone ). org.compiere.grid Implementa datagrid, application dialog personalizzati e tabpane per le finestre 33

34 Marco Lui Capitolo 3 - Metodologia dell applicazione. org.compiere.grid.ed Gestisce alcuni elementi dell ambiente grafico, come finestre, calendario, pannelli org.compiere.grid.tree Creazione di un modello ad albero, basandosi su MTree (org.compiere.model). org.compiere.install Gestione e importazione delle traduzioni. org.compiere.minigrid JTable personalizzate nelle form dell applicazione client. org.compiere.pos Point Of Sale per il PC terminale. org.compiere.print Controller dei report e della stampa. org.eevolution.form Contiene una classe per la gestione manuale delle spedizioni. Tabella Packages contenuti nella cartella sqlj/src Package org.compiere.sqlj Descrizione Contiene le classi per le query con sqlj. I metodi sono suddivisi a seconda dell oggetto a cui si riferiscono: Account, BPartner, Currency, Invoice, Payment, Product Tabella Packages contenuti nella cartella install/src Package org.compiere.install Descrizione Contiene l interfaccia Config e le classi che la implementano. Queste classi servono per la configurazione durante l installazione di JBoss, Glassfish, DB Oracle, DB PostgreSQL, JVM, Open e Apple JVM, e le classi per le traduzioni nelle varie lingue delle finestre di setup. 34

35 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Tabella Packages contenuti nella cartella Extend/src Package compiere.model org.compiere.test; test; test.functional; test.functional.inventory; test.performance Descrizione Esempi di modelli. Packages che contengono solo classi di test. Tabella Packages contenuti nella cartella serverroot/src/main/ejb Package org.compiere.session Descrizione Package che contiene diverse classi per la gestione dei Java Beans. Tabella Packages contenuti nella cartella serverroot/src/main/server Package org.adempiere.server.rpl; org.adempiere.server.rpl.impl org.compiere.ldap org.compiere.server Descrizione Packages che contengono interfaccia e implementazione del processo per l importazione. Gestione delle connessione ldap e decodifica dei messaggi. Contiene la classe AdempiereServer e AdempiereServerMgr come manager del server. Presenta poi delle classi Processor per l Account, Alert, , Replication, Request, Workflow, le quali estendono la classe AdempiereServer. Tabella Packages contenuti nella cartella serverroot/src/main/servlet Package org.compiere.web Descrizione Gestione delle servlet e monitor del server. 35

36 Marco Lui Capitolo 3 - Metodologia Tabella Packages contenuti nella cartella serverapps/src/main/servlet Package org.compiere.wstore org.compiere.www Descrizione Contiene servlet. Contiene servlet. Tabella Packages contenuti nella cartella zkwebui/web-inf/src Package org.adempiere.webui Descrizione Gestione dell interfaccia grafica web. Ci sono diversi altri package, che ricalcano la classificazione del client, ma per il servizio web (es: apps, form, graph, grid, install, util ) Tabella Packages contenuti nella cartella JasperReports/src Package org.compiere.report org.compiere.utils Descrizione Contiene le classi per la creazione dei report tramite le librerie Jasper Report. Contiene una classe per il digest dei file. Tabella Packages contenuti nella cartella JasperReportsWebApp/src Package org.compiere.ejb org.compiere.interfaces org.compiere.utils org.compiere.web Descrizione Bean per l hash MD5. Interfaccia MD5. Test per MD5. Servlet per ottenere l MD5. Tabella Packages contenuti nella cartella tools/src Package org.apache.ecs Descrizione Classi che permettono di creare codice di markup (come html) tramite oggetti java. 36

37 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software org.apache.ecs.filter Classi per creare filtri. org.apache.ecs.storage Definisce un oggetto di tipo Array, con tutti i metodi per gestirlo. org.apache.ecs.xhtml Contiene diverse classi. Ognuna si occupa di creare un tipo di tag html. org.apache.xml Contiene classi per la creazione di documenti xml e la creazione di generici tag. Tabella Packages contenuti nella cartella webcm/src/main/servlet Package Descrizione og.compiere.cm Ridefinisce una HttpServlet con la possibilità di salvare qualche global enviroment e cache. Definisce poi alcune singole servlet. og.compiere.cm.extend Contiene una classe che cerca l indice del risultato. org.compiere.cm.cache Gestione della cache nel web server per ridurre il carico del DB e velocizzare il caricamento delle pagine. org.compiere.cm.request Contiene una classe per creare o aggiornare Requests. org.compiere.cm.utils Qualche classe aggiuntiva per le servlet. og.compiere.cm.xml Generazione di xslt. Tabella Packages contenuti nella cartella migration/src Package oracle Descrizione Permette la migrazione da un database oracle ad un altro. 37

38 Marco Lui Capitolo 3 - Metodologia Tabella Packages contenuti nella cartella posterita/posterita/src/main Package Diversi package Descrizione Contiene tutte le classi per la gestione POS tramite Posterita. 3.3 Fase 2: Ricerca di classi e metodi significativi 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 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 Test and Performance Tools Platform (TPTP) TPTP è un plug-in della nota piattaforma di programmazione Eclipse. 38

39 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 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 Esiste una versione più recente della piattaforma, chiamata Indigo, ma non supporta più TPTP, in quanto la è 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. 39

40 Marco Lui Capitolo 3 - Metodologia 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. Figura Risultati di un'esecuzione esempio visualizzati con TPTP 40

41 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 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 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 41

42 Marco Lui Capitolo 3 - Metodologia 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. 3.4 Fase 3: Testing Per effettuare dei test in maniera precisa e riproducibile si è deciso di seguire questa procedura, ovvero di estrapolare le problematiche riscontrate e creare dei piccoli programmi su cui testarle indipendentemente. In questo modo non è più necessario eseguire l intero programma Adempiere, ma riprodurre solo le parti interessanti. I test eseguiti possono essere raggruppati in tre categorie: Test su if concatenati e switch Test sugli iteratori Test sulle stringhe Test su if concatenati e switch Per eseguire questi test si è creato un piccolo programma che riproducesse una singola funzionalità, focalizzandoci in particolare sul metodo load. Queste sono le classi che compongono il mini programma di test: 42

43 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Classe PO: contiene un oggetto di nome p_info, di tipo POInfo; Classe POInfo: contiene un array chiamato m_columns, costituito da oggetti di tipi POInfocolumn; Classe POInfoColumn: contiene le informazioni su una singola colonna della tabella. Vengono indicati l identificativo della tabella, il nome, le chiavi e alcune informazioni relative alla crittazione e sul tipo di dati contenuti. Presenta un costruttore che riceve tutti questi parametri e li salva in variabili locali. In particolare è presente la variabile ColumnClass, definita come oggetto generico Class<?>. La sua tipologia viene scelta in base al valore della stringa columnname e può assumere valori come String, Boolean, Integer, BigDecimal, Timestamp e altri. Esempio codice: if (columnname.equals( AD_Language ) columnname.equals( EntityType )) {ColumnClass = String.class; Nella classe PO viene riportato il metodo load originale, cioè quello presente in Adempiere, il quale presenta un ciclo for sugli oggetti presenti nell array m_columns presente nell oggetto p_info. All interno del ciclo si ottengono i valori di ColumnName e ColumnClass. Quest ultimo viene utilizzato come fattore discriminante nella serie di if concatenati successivi. for (index = 0; index < size; index++) { String columnname = p_info.getcolumnname(index); Class<?> clazz = p_info.getcolumnclass(index); int dt = p_info.getcolumndisplaytype(index); if (clazz == Integer.class) { ; 43

44 Marco Lui Capitolo 3 - Metodologia else if (clazz == BigDecimal.class) { ; else if (clazz == Boolean.class) { ; else if (clazz == Timestamp.class) { ; { Figura Class Diagram del programma usato per il test su if concatenati Una possibile alternativa al codice sopra riportato è quella di sostituire gli if con uno switch. Sorge però un problema: questo costrutto è in grado di lavorare esclusivamente con oggetti di tipo intero o enumerativi. 44

45 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Per non modificare anche le altre classi si è pensato ad una soluzione alternativa, ovvero fare in modo di mappare gli oggetti di tipo class in enumerativi. Per prima cosa è necessario creare un tipo enum con i valori che può assumere la variabile ColumnClass. public enum TipoClasse { String, Integer, BigDecimal, Boolean, altro; Bisogna ora ottenere questi valori, estrapolandoli dall oggetto clazz. Per prima cosa è necessario ottenere una stringa con il nome completo del tipo classe mediante un semplice metodo tostring() applicato all oggetto clazz. I risultati saranno del tipo class java.lang.string, oppure java.math.integer ecc Successivamente si deve ottenere la sottostringa eliminando la prima parte non interessante e lasciando solo il tipo di classe presente nell enum, come String o Integer. Utilizzando Java 7 è possibile utilizzare direttamente le stringhe nella valutazione dello switch. Non è stato però utilizzato in quanto si è preferito un metodo standard e retro compatibile. A questo punto si è potuto applicare lo switch utilizzando il metodo valueof, il quale associa il valore del parametro passato ad un oggetto del tipo enum definito precedentemente. Class<?> clazz = p_info.getcolumnclass(index); String clazz2 = clazz.tostring().substring(16); switch (TipoClasse.valueOf(clazz2)) { case altro: { ; case String: { ; 45

46 Marco Lui Capitolo 3 - Metodologia break; case Integer: { ; break; case BigDecimal: { ; break; case Boolean: { ; break; All interno dei case sono state sostituite tutte le istruzione con delle semplici stampe a video, in modo da evidenziare i tempi di esecuzione dei costrutti esaminati rispetto ai metodi chiamati all interno. L array m_columns contenente oggetti di tipo POInfoColumn è stato popolato artificialmente con 10 oggetti e si è fatto in modo che in entrambi i casi il numero di if o di case esaminati fosse lo stesso. Sono stati sempre eseguiti almeno 5 test per poi fare una media dei risultati ottenuti. Si è sempre controllato che i dati fossero coerenti tra loro facendo in modo che il valore della confidenza sul valore medio fosse al di sotto del 5%. Ecco in dettaglio un esempio (Tabella 3.20). Tabella Dati di esempio per il calcolo della confidenza Dato 1 Dato 2 Dato 3 Dato 4 Dato 5 Valore 0, , , , ,

47 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Numero valori: 5 Media: Deviazione standard = Alfa (sempre costante) = 0.05 Confidenza = Confidenza / Media = 0.9% Nel caso in cui questo valore superasse la soglia del 5% verrebbero ripetuti i test e ottenuti nuovi dati. Questa procedura è necessaria per evitare che certi valori fuori dalla norma o errori occasionali influiscano sui valori medi. Oltre a questo test ne sono stati eseguiti altri per monitorare il comportamento del programma alla modifica di alcuni parametri, come il numero di if concatenati o case presenti e il numero di oggetti presenti nell array su cui fare la valutazione. Si è inoltre considerata l ipotesi di sostituire il ciclo for con un equivalente ciclo while, in modo da valutare quale dei due fosse il più efficiente Test sugli iteratori La seconda problematica su cui si è lavorato riguarda i cicli for, in cui potrebbe essere conveniente utilizzare degli iteratori. Gli iteratori permettono di valutare gli elementi presenti in un contenitore, come un vettore o una lista, indipendentemente dal tipo di oggetto presente. Il meccanismo di iterazione si preoccupa di ricordare quali elementi sono già stati esaminati e quale il prossimo. Per poter utilizzare un iteratore sono necessari questi passi: Implementare l interfaccia Iterator, che comprende la definizione di alcuni metodi (di solito l implementazione avviene utilizzando le inner classes, ovvero viene definita all interno della classe del contenitore): 47

48 Marco Lui Capitolo 3 - Metodologia boolean hasnext(), che ritorna true se esistono ancora elementi da visitare; Object next(), che ritorna l elemento successivo; void remove(), che rimuove l ultimo elemento ritornato dall iteratore. Definire e implementare nel tipo contenitore un metodo che restituisce un iteratore. Per effettuare i test si è utilizzato lo stesso programma implementato per il test sullo switch, ma chiaramente sostituendo il ciclo for con un iteratore. Per maggiore chiarezza verranno riportati i pezzi di codice che riguardano l implementazione dell iteratore. Classe POInfo: public class POInfo { Vector<POInfoColumn> v = new Vector<POInfoColumn>(); /** * Costruttore Classe POInfo */ public POInfo () { for (int i = 0; i < 10; i++) { /** * Implementazione dell interfaccia Iterator */ class VIterator implements Iterator<Object> { private int i; VIterator() { i = 0; public boolean hasnext() { return i < v.size(); 48

49 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software public Object next() { if (i < v.size()) { i++; return v.get(i - 1); else throw new NoSuchElementException(""); public void remove() { /** * Metodo che restituisce un nuovo iteratore */ public Iterator<?> iterator() { return new VIterator(); Metodo load della classe PO: public void load() { Iterator<?> it = p_info.v.iterator(); while (it.hasnext()) { I test si sono svolti su quattro versioni del programma utilizzato per lo switch, provando tutte le combinazioni possibili, ovvero: Metodo load con ciclo for e all interno una serie di if concatenati. Metodo load con ciclo for e all interno uno switch. Metodo load con iteratore e all interno una serie di if concatenati. Metodo load con iteratore e all interno uno switch. 49

50 Marco Lui Capitolo 3 - Metodologia I primi due sono una copia di quelli utilizzati nei precedenti test, ma sono stati presi in considerazione per effettuare un confronto con le versioni con l iteratore. Si è poi aumentato il numero di oggetti presenti nei vettori o array in modo da valutare l andamento dei tempi di esecuzione in relazione al numero di iterazioni. Per l analisi dei dati si è seguita la stessa procedura riportata per i test precedenti, ovvero media su cinque valori e controllo della confidenza Test sulle stringhe: StringBuilder e StringBuffer Analizzando il codice del metodo convertstatement presente nella classe Convert si è notato un utilizzo molto intensivo delle stringhe. Le operazioni tipiche che si possono trovare riguardano la creazione di sottostringhe, ricerca di caratteri e concatenamenti. Ogni singola operazione potrebbe non essere così impattante sul tempo di esecuzione, ma dato che le stringhe vengono comunemente usate in quasi tutte le classi, anche un piccolo miglioramento potrebbe portare un contributo significativo in ottica globale. Viene ora riportata una parte del codice del metodo convertstatement con la relativa analisi protected ArrayList<String> convertstatement(string sqlstatement) { int found_next_function = sqlstatement.touppercase(). indexof("nextidfunc("); if (found_next_function <= 0) found_next_function = sqlstatement.touppercase().indexof("nextid("); if (found_next_function > 0) { boolean SYSTEM_NATIVE_SEQUENCE = true; boolean adempieresys = false; if (SYSTEM_NATIVE_SEQUENCE &&!adempieresys) { String function_before = sqlstatement.substring(0, 50

51 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software found_next_function); String function_start = sqlstatement.substring( found_next_function); String function_after = function_start.substring (function_start.indexof(")") + 1); String sequence = function_start.substring( function_start.indexof("(") + 1, function_start.indexof(",")); int separator = function_start.indexof("'") +1; String next = function_start.substring( separator); String system = next.substring(0,next.indexof("'")); 1 Il metodo riceve una stringa sqlstatement come parametro di ingresso. 2 3 Si ottiene la versione con tutti i caratteri maiuscoli della stringa e si cerca all interno di 4 essa la sottostringa NEXTIDFUNC( 5 Se non viene trovata si cerca la sottostringa NEXTID( 6 7 Se l intero found_next_function è positivo (ovvero è stata trovata una delle due 8 sottostringhe precedenti) si setta la variabile booleana SYSTEM_NATIVE_SEQUENCE 9 al valore true, e la booleana adempieresys a false. 10 Si verifica che le variabili booleane siano state settate correttamente. 11 Si estrae una sottostringa da sqlstatement dal primo carattere fino all intero 12 found_next_function calcolato precedentemente, ovvero l indice che segna l inizio di 13 NEXTID( o NEXTIDFUNC(. La nuova stringa viene chiamata function_before. 14 Si estrae una sottostringa da sqlstatement dal carattere con indice uguale all intero 15 found_next_function fino alla fine. La nuova stringa viene chiamata function_start. 51

52 Marco Lui Capitolo 3 - Metodologia Viene estratta una sottostringa da function_start, che inizia il carattere seguente la prima chiusura di parentesi tonda, fino alla fine. La nuova stringa viene chiamata function_after. Viene estratta una sottostringa da function_start, che inizia il carattere seguente la prima apertura di parentesi tonda, fino alla prima virgola trovata. La nuova stringa viene chiamata sequence. Si cerca nella stringa function_start la posizione in cui è presente il primo apice. Al risultato viene sommato 1 e il valore salvato nell intero separator. Viene estratta una sottostringa da function_start, che inizia con il carattere indicato dall intero separator, fino alla fine. La nuova stringa viene chiamata next. Viene estratta una sottostringa da next, che inizia con il primo carattere e termina con il primo apice trovato. La nuova stringa viene chiamata system. Per comprendere meglio il funzionamento di questo metodo viene riportato un esempio di esecuzione con i valori assunti dalle singole stringhe. Ipotizziamo che il parametro sqlstatement in ingresso venga inizializzato in questo modo: String sqlstatement = wxyz NEXTIDFUNC(parametro 1, parametro 2) xxx ' yyy ' zzz int found_next_function = sqlstatement.touppercase().indexof( "NEXTIDFUNC("); found_next_function: 5 if (SYSTEM_NATIVE_SEQUENCE &&!adempieresys) { String function_before = sqlstatement.substring (0,found_next_function); function_before: wxyz String function_start = function_start: 52

53 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software sqlstatement.substring (found_next_function); NEXTIDFUNC(parame tro 1, parametro 2) xxx ' yyy ' zzz String function_after = function_start.substring (function_start.indexof(")") + 1); function_after: yyy ' zzz xxx ' String sequence = function_start.substring (function_start.indexof("(") + 1, function_start.indexof(",")); sequence: parametro 1 int separator = function_start.indexof("'") + 1; separator: 42 String next = function_start.substring(separator); next: yyy ' zzz String system = next.substring (0,next.indexOf("'")); system: yyy Dato che le stringhe vengono ampiamente utilizzate e manipolate, si è cercato un modo per renderle più efficienti. Si è pensato di sostituire le stringhe con degli oggetti molto simili, ovvero gli oggetti StringBuilder e StringBuffer. La differenza sostanziale è che le stringhe sono oggetti non modificabili; ciò comporta che se si avesse la necessità di concatenare dei caratteri, o ottenere una parte di stringa, si dovrebbe necessariamente creare una nuova stringa. Come si vede nel codice di convertstatement, quando si ha bisogno di una sottostringa si deve necessariamente creare una nuova stringa. 53

54 Marco Lui Capitolo 3 - Metodologia Gli oggetti di tipo StringBuilder e StringBuffer invece possono essere modificati e mettono a disposizione alcuni metodi in grado di farlo, come il metodo append che permette di aggiungere caratteri in fondo alla stringa, oppure delete che permette la cancellazione di uno o più caratteri all interno della stringa. Vista la necessità di manipolare numerose stringhe si è pensato che avere a che fare con un oggetto più flessibile potesse migliorare le prestazioni. La differenza tra i due tipi sta nel fatto che il tipo StringBuffer è thread-safe, ovvero garantisce affidabilità in presenza di più thread che potrebbero agire sull oggetto. Per effettuare i test sono stati implementati 4 metodi convertstatement: 1. Convert1: il metodo originale visto in precedenza 2. Convert2: viene utilizzato il tipo StringBuilder al posto di string. static String convert2(string sqlstatement) { int found_next_function = sqlstatement.touppercase().indexof("nextidfunc(" ); StringBuilder function_before = new StringBuilder (sqlstatement); StringBuilder function_start = new StringBuilder( sqlstatement); function_before = function_before.delete (found_next_function, function_before.length()); function_start = function_start.delete(0, found_next_function); int separator = function_start.indexof("'") + 1; 54

55 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software StringBuilder system = new StringBuilder(function_start); function_start = function_start.delete(0, function_start.indexof(")") + 1); system = system.delete(0, separator); system = system.delete(system.indexof("'"), system.length()); return system.tostring(); Le operazioni di substring sono state sostituite con il metodo delete, per eliminare i caratteri in eccesso. 3. Convert3: viene utilizzato il tipo StringBuffer al posto di string. Il codice e le operazioni sono le stesse di Convert2. 4. Convert4: viene utilizzato il tipo StringBuffer al posto di string ed inoltre gli oggetti di tipo StringBuffer vengono inizializzati con la preallocazione dello spazio necessario. static String convert4(string sqlstatement) { int found_next_function = sqlstatement.touppercase().indexof( "NEXTIDFUNC("); StringBuffer function_before = new StringBuffer (sqlstatement.length()).append(sqlstatement); StringBuffer function_start = new StringBuffer 55

56 Marco Lui Capitolo 3 - Metodologia (sqlstatement.length()).append(sqlstatement); function_before = function_before.delete (found_next_function, function_before.length()); function_start = function_start.delete(0, found_next_function); int separator = function_start.indexof("'") + 1; StringBuffer system = new StringBuffer (function_start.length()).append(function_start) ; function_start = function_start.delete (0,function_start.indexOf(")") + 1); system = system.delete(0, separator); system = system.delete(system.indexof("'"), system.length()); return system.tostring(); Da notare che nel metodo originario vengono create le stringhe ricalcando la gerarchia di Figura 3.7. Le stringhe segnate con uno sfondo blu sono quelle che realmente vengono utilizzate, mentre le altre sono solo come passaggio per ulteriori manipolazioni. Per questo motivo le stringhe inutili non sono state create negli altri metodi Convert. 56

57 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software sqlstatement function_before function_start function_after next sequence system Figura Gerarchia stringhe utilizzate nel metodo convert I test effettuati hanno ricalcato la stessa procedura descritta in precedenza, quindi 5 prove per ogni metodo, con controllo della confidenza Test sulle stringhe: substring Analizzando il codice di convertstatement si nota come uno dei metodi più utilizzati sulle stringhe sia substring. Si è pensato quindi a qualche alternativa per implementare la stessa funzione, ma utilizzando altri metodi. Sono state create quindi altre 5 alternative al classico metodo substring. 1. Sub1: metodo substring classico, che per poterlo comparare con gli altri è stato incapsulato in una funzione. static String sub1(string str, int begin, int end) { return str.substring(begin, end); 57

58 Marco Lui Capitolo 3 - Metodologia 2. Sub2: utilizza il metodo getchars(int begin, int end, char[] dest, int index). Questo metodo preleva dalla stringa su cui è chiamato i caratteri compresi tra gli indici begin ed end, inserendoli nell array di caratteri dest dalla posizione indicata da index. Tutte e quattro le variabili necessarie vengono passate come parametro. Si è pensato quindi di ottenere i caratteri della sottostringa grazie a getchars per poi creare una stringa con questi caratteri. static String sub2(string str, int begin, int end) { char[] dest = new char[end - begin]; str.getchars(begin, end, dest, 0); return String.copyValueOf(dest); 3. Sub3: utilizza il metodo subsequence(int begin, int end), che restituisce un oggetto di tipo CharSequence con i caratteri compresi tra i due indici passati per parametro. Dato che il metodo dovrebbe ritornare una stringa è sufficiente generarla con il metodo tostring() applicato all oggetto CharSequence appena ottenuto. static String sub3(string str, int begin, int end) { return str.subsequence(begin, end).tostring(); 4. Sub4: utilizza il metodo charat(int index), che restituisce il carattere nella posizione indicata dall indice passato come parametro. Il metodo viene inserito un ciclo for per ottenere tutti i caratteri necessari alla composizione della sottostringa, che vengono man mano copiati in un array di char. Da questo array verrà poi creata la stringa finale da ritornare. Sono stati inseriti inoltre dei controlli per valutare la correttezza 58

59 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software degli indici passati come parametro. Infatti è necessario controllare che gli indici non siano negativi, che l indice di fine sottostringa sia maggiore di quello di inizio stringa ma non superiore alla lunghezza della stringa. Nei precedenti metodi non era necessario in quanto getchars e subsequence eseguono gli stessi controlli. static String sub4(string str, int begin, int end) throws IndexOutOfBoundsException { if ((begin < 0) (begin >= end) (end > str.length())) throw new IndexOutOfBoundsException(); char[] dest = new char[end - begin]; for (int index = begin; index < end; index++) { dest[index] = str.charat(index); return String.copyValueOf(dest); 5. Sub5: utilizza charat(int index) come il precedente Sub4, ma i caratteri vengono aggiunti ad un oggetto di tipo StringBuilder mediante il metodo append. Viene infine ottenuta la stringa grazie al metodo tostring() applicato all oggetto StringBuilder. static String sub5(string str, int begin, int end) throws IndexOutOfBoundsException { if ((begin < 0) (begin >= end) (end > str.length())) throw new IndexOutOfBoundsException(); StringBuilder dest = new StringBuilder(endbegin); for (int index = begin; index < end; index++) { dest.append(str.charat(index)); 59

60 Marco Lui Capitolo 3 - Metodologia return dest.tostring(); 6. Sub6: utilizza uno dei costruttori dell oggetto String, ovvero String(char[] value, int begin, int end-begin). Questo costruttore crea una nuova stringa copiando i caratteri presenti nell array passato per parametro, iniziando dal carattere presente nella posizione indicata dal parametro begin. Il numero di caratteri copiati viene definito dall altro parametro passato. L array passato per parametro viene riempito di tutti i caratteri contenuti nella stringa di partenza mediante il metodo tochararray(). static String sub6(string str, int begin, int end) throws IndexOutOfBoundsException { if ((begin < 0) (begin >= end) (end > str.length())) throw new IndexOutOfBoundsException(); char[] value = str.tochararray(); return ((begin == 0) && (end == str.length()))? str : new String(value, begin, end - begin); Sono state seguite le solite procedure descritte in precedenza in modo da ottenere valori medi significativi. Si è pensato inoltre se i tempi di esecuzione potessero essere influenzati dalla lunghezza della sottostringa da ottenere. Per questo motivo sono stati ripetuti tutti i test con diverse lunghezze della sottostringa, ovvero 1, 100, e caratteri. 60

61 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Test sulle stringhe: concatenamento Un operazione molto comune che può essere effettuata con le stringhe è il loro concatenamento. Un metodo tipico è quello di utilizzare il simbolo + tra le stringhe. Verrà creata una nuova stringa contenente il concatenamento tra le due. Naturalmente il concatenamento può essere ripetuto più volte consecutivamente. Il prezzo da pagare per questa comoda operazione è però il costo della creazione di una nuova stringa. Si è pensato quindi che se si utilizzasse un oggetto di tipo StringBuilder o StringBuffer non si avrebbe più questo costo, ma si andrebbe a modificare l oggetto stesso. Sono perciò state create 3 varianti del concatenamento. 1. Metodo1: concatenamento classico mediante il simbolo +. All interno del metodo sono state create delle stringhe e poi concatenate. static String metodo1() { String prova1 = "prova1"; String prova2 = "prova2"; String prova3 = "prova3"; String prova4 = "prova4"; String prova5 = "prova5"; String prova6 = "prova6"; String prova7 = "prova7"; String prova8 = "prova8"; String prova9 = "prova9"; String prova10 = "prova0"; return prova1 + prova2 + prova3 + prova4 + prova5 + prova6 + prova7 + prova8 + prova9 + prova10; 61

62 Marco Lui Capitolo 3 - Metodologia 2. Metodo2: concatenamento con oggetto di tipo StringBuffer. All interno del metodo sono state create delle stringhe e un oggetto di tipo StringBuffer con la preallocazione della memoria necessaria. Sono state poi aggiunte all oggetto StringBuffer tutte le altre stringhe mediante il metodo append. static String metodo2() { String prova1 = "prova1"; String prova2 = "prova2"; String prova3 = "prova3"; String prova4 = "prova4"; String prova5 = "prova5"; String prova6 = "prova6"; String prova7 = "prova7"; String prova8 = "prova8"; String prova9 = "prova9"; String prova10 = "prova0"; StringBuffer prova = new StringBuffer(60); return(prova.append(prova1).append(prova2). append(prova3).append(prova4).append(prova5). append(prova6).append(prova7).append(prova8). append(prova9).append(prova10).tostring()); 3. Metodo3: concatenamento con oggetto di tipo StringBuilder. Sostanzialmente identico al precedente, ma con l utilizzo di un oggetto di tipo StringBuilder al posto di un oggetto di tipo StringBuffer. static String metodo3() { String prova1 = "prova1"; String prova2 = "prova2"; String prova3 = "prova3"; 62

63 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software String prova4 = "prova4"; String prova5 = "prova5"; String prova6 = "prova6"; String prova7 = "prova7"; String prova8 = "prova8"; String prova9 = "prova9"; String prova10 = "prova0"; StringBuilder prova = new StringBuilder(60); return(prova.append(prova1).append(prova2). append(prova3).append(prova4).append(prova5). append(prova6).append(prova7).append(prova8). append(prova9).append(prova10).tostring()); Si è pensato però anche un altro test per fare in modo che il tempo impiegato per la generazione delle stringhe da concatenare non influenzasse il vero obiettivo, ovvero il tempo di esecuzione del concatenamento. La dichiarazione delle stringhe è stata quindi spostata all esterno, creando degli attributi statici modificabili da tutti metodi. Il tempo di esecuzione del metodo si rivela quindi più aderente al tempo di esecuzione del concatenamento al suo interno Test sulle stringhe: metodi generici I tipi StringBuilder e StringBuffer sono molto simili al tipo string e condividono molti metodi comuni. Risulta quindi interessante capire quali sono le prestazioni dei 3 tipi riguardo ai classici metodi in comune. È infatti importante non solo studiare il loro comportamento su implementazioni alternative come nei test precedenti, ma anche sugli stessi metodi. Sono stati scelti due metodi tra quelli in comune, ovvero charat(int index) e getchars(int begin, int end, char[] dest, int destbegin). 63

64 Marco Lui Capitolo 3 - Metodologia È stato valutato il tempo di esecuzione di questi due metodi con tutti e tre i tipi disponibili, ovvero la classica stringa, StringBuilder e StringBuffer. Viene riportato ora il codice dei metodi per il testing di charat. Come si può notare non viene fatto altro che passare i parametri necessari, ovvero un oggetto stringa (o StringBuffer o StringBuilder) e l indice del carattere da prelevare. static void charatstring(string str, int index) { str.charat(index); static void charatbuffer(stringbuffer str, int index) { str.charat(index); static void charatbuilder(stringbuilder str, int index) { str.charat(index); Viene riportato ora il codice dei metodi per il testing di getchars. Vengono passati per parametro: Una stringa (o StringBuffer, o StringBuilder) str. Un intero inizio, per indicare il primo carattere da prelevare. Un intero fine, per indicare l ultimo carattere da prelevare. Un array di char temp, che verrà riempito dei caratteri prelevati. Un intero offset, per indicare da quale posizione cominciare a copiare i caratteri all interno dell array temp. static void getcharsstring (String str, int inizio, int fine, char[] temp, int offset) { 64

65 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software str.getchars(inizio, fine, temp, offset); static void getcharsbuffer(stringbuffer str, int inizio, int fine,char[] temp, int offset) { str.getchars(inizio, fine, temp, offset); static void getcharsbuilder(stringbuilder str, int inizio, int fine, char[] temp, int offset) { str.getchars(inizio, fine, temp, offset); Test finale: programma ad hoc Per capire meglio le potenzialità delle migliorie trovate si è pensato di testarle con un piccolo programmino ad hoc che condensasse gran parte dei costrutti analizzati. Questo programma rispecchia la struttura vista nel programma utilizzato per gli altri test su if concatenati e switch, ma sono stati introdotti anche iteratori e concatenamenti di stringhe. Sono state implementate due versioni: una standard ricalcante il codice di Adempiere (chiamata as-is ) e una con tutte le migliorie trovate (chiamata mod ). Il programma as-is è composto da 4 classi. 1. MainAsIs: crea un oggetto di tipo POasis e ne chiama il metodo load. Questo ritorna una stringa che viene stampata a video. public class MainAsIs { public static void main(string[] args) { POasis oggettopo = new POasis(); System.out.println("Totale: " + oggettopo.load()); 65

66 Marco Lui Capitolo 3 - Metodologia 2. POasis: il costruttore crea un oggetto di tipo POInfoAsis. Il metodo load presenta un ciclo for che scandisce l array contenuto nell oggetto POInfoAsis (si veda poi la classe in seguito). Contiene una serie di if concatenati ed effettua un concatenamento tra diverse stringhe. Il risultato verrà poi ritornato alla classe MainAsis chiamante. public class POasis { protected volatile POInfoAsis p_info = null; private int a = 0; public POasis() { p_info = new POInfoAsis(); protected String load() { int size = p_info.getcolumncount(); int index = 0; int x = 0; String totale = ""; for (index = 0; index < size; index++) { String columnname = p_info.getcolumnname(index); int dt = p_info.getcolumndisplaytype(index); Class<?> clazz = p_info.getcolumnclass(index); if (clazz == Integer.class) x = 1; else if (clazz == BigDecimal.class) x = 2; else if (clazz == Boolean.class) x = 3; 66

67 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software else if (clazz == Timestamp.class) x = 4; else if (a == 1) x = 5; else if (clazz == String.class) x = 6; else x = 7; totale = totale + columnname + " = " + dt + ", x = " + x + "; "; return totale; 3. POInfoAsis: crea un array di oggetti di tipo POInfoColumnAsis. Il costruttore lo inizializza con dei valori casuali. Contiene inoltra alcuni metodi getter per ritornare informazioni su questi oggetti. public class POInfoAsis { private POInfoColumnAsis[] m_columns = new POInfoColumnAsis[10]; public POInfoAsis() { for (int i = 0; i < 10; i++) { m_columns[i] = new POInfoColumnAsis( "Colonna" + i, i + 10); public int getcolumncount() { return m_columns.length; 67

68 Marco Lui Capitolo 3 - Metodologia public String getcolumnname(int index) { if (index < 0 index >= m_columns.length) return null; return m_columns[index].columnname; public Class<?> getcolumnclass(int index) { if (index < 0 index >= m_columns.length) return null; return m_columns[index].columnclass; public int getcolumndisplaytype(int index) { return m_columns[index].displaytype; 4. POInfoColumnAsis: contiene una serie di attributi (int, string e boolean principalmente) che vengono inizializzati con il costruttore, il quale vi copia i valori passati per parametro. Qui sono riportati solo gli attributi e le istruzioni più significative. public class POInfoColumnAsis { public String ColumnName; public int DisplayType; public Class<?> ColumnClass; public POInfoColumnAsis(String columnname,,int displaytype) { ColumnName = columnname; DisplayType = displaytype; if (columnname.equals("ad_language") 68

69 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software { ColumnName.equals("EntityType")) { ColumnClass = String.class; else if (columnname.equals("posted") columnname.equals("processed") columnname.equals("processing")) { ColumnClass = Boolean.class; else if (columnname.equals("record_id")) ColumnClass = Integer.class; else ColumnClass = String.class; Il programma mod è anch esso composto da 4 classi: MainMod: non vi sono modifiche rilevanti. public class MainMod { public static void main(string[] args) { POMod oggettopo = new POMod(); System.out.println("Totale: " + oggettopo.loadmod()); POMod: è stato inserito un iteratore per la scansione degli oggetti presenti nell array. Sono stati inoltre sostituiti gli if concatenati con un semplice switch. Rispetto all implementazione effettuata nei precedenti test si è pensato di migliorare ulteriormente lo switch andando a valutare un intero. Ciò è stato possibile creando una sorta di mappa tra i valori 69

70 Marco Lui Capitolo 3 - Metodologia dell attributo ColumnClass con dei semplici numeri interi. La mappa utilizzata viene riportata nella Tabella public class POMod { protected volatile POInfoMod p_info = null; private int a = 0; private int x = 0; public POMod() { p_info = new POInfoMod(); protected String loadmod() { StringBuilder totale = new StringBuilder(300); Iterator<?> it = p_info.v.iterator(); while (it.hasnext()) { POInfoColumnMod locale = (POInfoColumnMod) it.next(); int clazz = locale.classint; switch (clazz) { case 0: x = 7; case 3: x = 1; break; case 4: x = 2; break; case 2: x = 3; break; case 5: x = 4; break; case 6: 70

71 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software x = 5; break; case 1: x = 6; break; totale.append(locale.columnname). append(" = ").append (locale.displaytype).append(", x = "). append(x).append("; "); return totale.tostring(); POInfoMod: in questa classe è stata aggiunta l implementazione dell iteratore tramite inner class. È stato inoltre sostituito l array con un vettore equivalente. public class POInfoMod { Vector<POInfoColumnMod> v = new Vector<POInfoColumnMod>(); public POInfoMod() { for (int i = 0; i < 10; i++) { v.addelement(new POInfoColumnMod("Colonna" + i, i + 10); class VIterator implements Iterator<Object> { private int i; 71

72 Marco Lui Capitolo 3 - Metodologia VIterator() { i = 0; public boolean hasnext() { return i < v.size(); public Object next() { if (i < v.size()) { i++; return v.get(i - 1); else throw new NoSuchElementException(""); public void remove() { public Iterator<?> iterator() { return new VIterator(); POInfoColumnMod: è stato aggiunto un attributo intero da utilizzare con lo switch. public class POInfoColumnMod { [ ] public int ClassInt; [ ] public POInfoColumnMod() { [ ] if (columnname.equals("ad_language") columnname.equals("entitytype")) { 72

73 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software ColumnClass = String.class; ClassInt = 1; else if (columnname.equals("posted") columnname.equals("processed") columnname.equals("processing")) { ColumnClass = Boolean.class; ClassInt = 2; else if (columnname.equals("record_id")) { ColumnClass = Integer.class; ClassInt = 3; else { ColumnClass = String.class; ClassInt = 1; [ ] Tabella Mappa valori tra ColumnClass e ClassInt ColumnClass ClassInt String 1 Boolean 2 Integer Fase 4: Analisi risultati e stesura regole Tutti i test riportati precedentemente sono stati eseguiti utilizzando la piattaforma Eclipse e raccogliendo i dati tramite il plug-in TPTP. L output di questo plug-in è costituito dai tempi di esecuzione di tutti i metodi, raggruppabili per classi e per package. Questi tempi sono specificati in quattro modi diversi, ovvero Base Time, Average Base Time, Cumulative Time e Cumulative CPU Time. 73

74 Marco Lui Capitolo 3 - Metodologia Il plug-in permette di esportare questi dati creando dei report in formato tabulare csv, i quali però sono poco intuitivi e difficili da interpretare. Per questo motivo sono stati importati e puliti in un foglio di calcolo. Grazie agli strumenti messi a disposizione dai fogli di calcolo è stato molto più semplice elaborarli e trarne informazioni utili. Sono stati calcolati i valori medi di tutti i tempi, controllando sempre che i test rispettassero le condizioni di confidenza. In caso contrario i test venivano scartati e rieseguiti. Sono stati creati inoltre diversi grafici comparativi per evidenziare le diversità nei tempi di esecuzione tra le versioni originali e modificate. A seconda del tipo di test sono stati presi in considerazione maggiormente i base time o i cumulative time, in base alle esigenze. Dai risultati ottenuti è stato possibile arrivare alla stesura di alcune regole che dovrebbero essere seguite per diminuire il tempo di esecuzione dei programmi Java. Da sottolineare che un minor tempo di esecuzione non si rispecchia necessariamente in un risparmio energetico. Infatti le istruzioni introdotte potrebbero essere più CPU intensive e richiedere un maggior dispendio di energia. Per questo motivo si è resa necessaria una validazione di questi risultati effettuando dei test energetici che ricalcassero quelli temporali fin qui eseguiti. 3.6 Fase 5: Test energetici Dopo aver effettuato tutti i test per misurare i tempi di esecuzione dei programmi era necessario trovare dei riscontri effettivi sui consumi. Si è reso quindi necessario misurare sperimentalmente i consumi energetici Strumentazione Esistono diversi strumenti in grado di rilevare l energia consumata, come gli electricity (o energy) meter, in grado di misurare la corrente assorbita da un carico elettrico; oppure le pinze amperometriche, in grado di rilevare la quantità di corrente senza bisogno di inserirle in serie al circuito come i classici amperometri. 74

75 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Questi strumenti non erano però indicati per i test da eseguire e si è preferito utilizzare un altro strumento, costruito da Formenti e Gallazzi [14] e descritto nel loro lavoro di tesi. Questo sistema è costituito da: System Board: posta a monte dell alimentatore del computer utilizzato per i test e permette di misurare il consumo energetico di tutto il sistema. Dato che non si era interessati a suddividere i consumi in base a CPU, RAM, dischi ecc questa soluzione pratica risulta essere perfetta per lo scopo. Figura System Board DAQ Board (Data Acquisition Board): collegata alla System Board, permette di acquisirne i segnali, elaborali e trasmetterli al PC. Per questi esperimenti è stato utilizzato il modello NI USB-6210 DAQ, prodotto dalla National Instruments, collegabili facilmente al PC tramite porta USB. 75

76 Marco Lui Capitolo 3 - Metodologia Figura NI USB-6210 DAQ Programma di acquisizione dati: riceve i dati dal DAQ, permettendo il loro salvataggio e la visualizzazione a video. Il programma si basa su LabVIEW (Laboratory Virtual Instrumentation Engineering Workbench), un ambiente di programmazione proprietario, sviluppato dalla National Instruments. Tale software presenta un interfaccia grafica che permette di visualizzare su un grafico l andamento della corrente e della potenza nel tempo. 76

77 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Figura Interfaccia del programma di acquisizione dati in LabVIEW PC Tester System Board DAQ PC con programma di acquisizione Figura Schema dei collegamenti del sistema di acquisizione dati 77

78 Marco Lui Capitolo 3 - Metodologia Preparazione ed esecuzione dei test Per effettuare i test energetici i programmi sono stati leggermente modificati in modo da aumentare la loro durata (qualche secondo di esecuzione) e rendere più semplice il processo di acquisizione. Ciò è stato fatto includendo la chiamata ai metodi interessati in un ciclo for. Il numero di iterazione è stato scelto di volta in volta in base ai test. Tramite la strumentazione vista si è in grado di rilevare il consumo energetico di tutto il sistema. Questo però non è esattamente l obiettivo del lavoro, che si focalizza invece sui consumi dei soli programmi test. È necessario quindi eliminare dal consumo ottenuto, quello relativo al mantenimento delle funzionalità di base del sistema, ovvero il consumo dell idle. Per ottenere questo valore è stata fatta un acquisizione del consumo mantenendo la macchina in uno stato di quiete, eliminando tutti i processi non fondamentali per il sistema. Sottraendo quindi il valore dell idle al consumo totale si otterrà il valore di energia netto del programma test. Il valore dell idle però non è sempre costante, ma varia nel tempo anche sulla stessa macchina e nelle stesse condizioni. Per questo motivo i dati acquisiti in sessioni diverse non possono condividere lo stesso valore di idle, ma va ricalcolato ogni volta. Anche tra le acquisizioni nella stessa sessione potrebbero esserci delle fluttuazioni che vanno considerate. Questi test però registrano una durata molto breve, di qualche secondo, e per questo risulta poco probabile un cambiamento nell idle così rapido. Ad ogni modo tutti i valori ottenuti sono stati ripetuti più volte e mediati, controllando sempre i limiti sulla confidenza già visti. In questo modo, anche se il valore di idle dovesse mutare tra un acquisizione e la successiva, i valori di energia ne subirebbero l influenza e i dati verrebbero scartati in quanto troppo distanti dagli altri valori. L output del programma di acquisizione è costituito da una serie di file di testo contenti diverse informazioni su potenza ed energia. Tra questi si sono valutati due file: uno contenente il valore di potenza istantanea ad ogni campionamento, e l altro contenente i risultati globali. In particolare quest ultimo riporta: 78

79 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Tempo di esecuzione del programma (in secondi); Potenza media, calcolata come valore medio tra tutte le potenze istantanee rilevate e salvate nell altro file (in Watt). Energia consumata, calcolata utilizzando l integrale della potenza nel tempo, mediante il metodo dei trapezi (in Joule). Wattora consumati, calcolati come Il software di acquisizione permette di eliminare direttamente l influenza dell idle se viene indicato il valore medio di potenza in quella situazione. Per questo motivo è stato inserito il valore di potenza media dell idle calcolato poco prima, in modo da ottenere già dei valori netti, senza bisogno di ulteriori manipolazioni. La procedura tenuta per lo svolgimento dei test è sempre stata la seguente: 1. Inizio acquisizione con programma in LabVIEW installato sul PC collegato al DAQ tramite porta USB. 2. Lancio del programma test sul PC collegato alla System Board. 3. Attesa della terminazione del programma test. 4. Arresto dell acquisizione con il programma in LabView. L inizio dell acquisizione e il lancio del programma non erano perfettamente sincronizzati, ma non risultava un problema in quanto avendo impostato il valore di potenza media dell idle direttamente nel programma il consumo in quel periodo veniva eliminato. Lo stesso discorso è valido per il tempo intercorso tra la terminazione del programma e l arresto dell acquisizione. I test energetici si sono concentrati sulla sostituzione degli if concatenati con lo switch e sul programma ad hoc. I risultati ottenuti sono stati confrontati con quelli precedenti ricavati con TPTP, per verificare l esistenza di una certa corrispondenza. Infine si è provato a calcolare una stima sul guadagno possibile di una esecuzione tipica del programma Adempiere. 79

80 Marco Lui Capitolo 3 - Metodologia Come esecuzione tipica si è preso l inserimento di un nuovo Business Partner. Sono stati rilevati i tempi di esecuzione di tutti i metodi mediante TPTP. Sono state scelte 20 tra le classi più significative, ovvero quelle con tempi di esecuzione più alti. Tutte queste classi assieme coprivano quasi il 50% del tempo totale di esecuzione. Sono stati analizzati i codici di queste classi alla ricerca di punti migliorabili; in particolar modo if concatenati e concatenamenti di diverse stringhe. Si è valutata poi la frequenza con cui questi obiettivi si ripetono rapportando il numero di linee di codice dei costrutti sul numero totale di linee di codice delle classi. Si è trovato così un valore percentuale approssimante la possibile influenza di questi blocchi di codice sul totale. Chiaramente questo è un valore grossolano, in quanto si basa su due ipotesi: Ogni istruzione ha lo stesso peso sul tempo di esecuzione Il codice è analizzato in maniera statica e quindi non è dato sapere quali parti di codice vengono eseguite (e quanto volte) e quali no. Queste due ipotesi inficiano chiaramente la bontà della stima, ma per il momento era sufficiente ottenere un indice grossolano per capire le potenzialità dei miglioramenti introdotti con l eliminazione delle problematiche su tutto un programma complesso come Adempiere. È stato calcolato poi il risparmio energetico per ogni classe ed effettuata la somma pesata di tutti i risparmi in base al tempo di esecuzione dei metodi di ogni classe. 80

81 Capitolo 4 4 Risultati e regole di ottimizzazione In questo capitolo verranno riportati tutti i risultati ottenuti dai test descritti nel capitolo precedente ed effettuati mediante l utilizzo del plug-in TPTP della piattaforma Eclipse. I risultati sono suddivisi per categoria: Risultati dei test su if concatenati e switch Risultati dei test sugli iteratori Risultati dei test sulle stringhe Risultati dei test sul programma ad hoc Per ogni categoria sono indicati i vari test effettuati, con i tempi di esecuzione e alcuni grafici di supporto per evidenziare meglio i risultati ottenuti. Dall analisi dell esito dei test sono state poi estrapolate alcune regole per la programmazione efficiente nel linguaggio Java. Il computer con il quale sono stati effettuati i test aveva le seguenti caratteristiche: Intel Core 2 Duo 2.00 GHz (2MB L2 Cache), FSB 800 MHz RAM da 2 GB DDR2 Sistema Operativo Microsoft Windows XP Professional 32-bit con SP3 81

82 Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 4.1 Risultati test su if concatenati e switch Sono stati effettuati alcuni test sulla sostituzione di if concatenati con uno switch. In seguito verranno riportati i risultati e le considerazioni di ogni singolo test If - switch a 7 scelte Il primo test si riferisce alla sostituzione di 7 if concatenati con un equivalente switch con 7 case. Il metodo load contenente gli if e lo switch esamina l array contenente 10 oggetti di tipo POInfoColumn. Nella Tabella 4.1 sono riportati i valori medi ottenuti dall esecuzione delle due versioni del programma test. Tabella Risultati test if - switch a 7 scelte Metodo Calls Base Time (s) Avg Base Time (s) Cumulative Time (s) load() , load2() 1 0, , , Con load si intende il metodo del programma contenente gli if concatenati, mentre con load2 si intende il metodo del programma modificato, ovvero quello contenente lo switch. In Tabella 4.2 e Tabella 4.3 vengono riportati rispettivamente i valori dei tempi di esecuzione dei metodi chiamati da load e da load2. I tempi di Cumulative CPU Time non sono stati riportati in quanto troppo piccoli per essere significativi. Tabella Tempi di esecuzione metodi chiamati da load Metodo Classe Calls Base Time (s) Avg Base Time (s) Cumulative Time (s) getcolumnname POInfo getcolumnclass POInfo getcolumndisplaytype POInfo getcolumncount PO

83 Base Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Tabella Tempi di esecuzione metodi chiamati da load2 Metodo Classe Calls Base Time (s) Avg Base Time (s) Cumulative Time (s) SWITCH PO valueof() PO getcolumnname() POInfo getcolumnclass() POInfo getcolumndisplaytype() POInfo getcolumncount() PO Gli istogrammi di Figura 4.1 e Figura 4.2 permettono di evidenziare bene le differenze sui tempi di esecuzione. 0, , , , , ,00015 load load2 0, , ,00000 Base Time Figura Grafico Base Time metodi load e load2 (a 7 scelte) 83

84 Cumulative Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , ,02000 load load2 0, ,00000 Cumulative Time Figura Grafico Cumulative Time metodi load e load2 (a 7 scelte) I metodi in comune chiamati da load e load2, ovvero getcolumnname, getcolumnclass, getcolumndisplaytype e getcolumncount, hanno riportato dei valori praticamente identici. Questo significa che non hanno avuto una maggiore influenza sui tempi di esecuzione di un metodo rispetto all altro. Si può notare che per il metodo load2 sono stati chiamati altri metodi per la gestione dello switch che hanno influito negativamente sulle sue performance. Infatti il Cumulative Time risulta molto più alto del Base Time, in quanto contiene i valori dei metodi chiamati. Nonostante ciò i tempi di esecuzione del metodo load2 sono nettamente migliori rispetto all originale load con gli if concatenati. Infatti il Cumulative Time di load2 è meno di un terzo rispetto a quello relativo al metodo load If - switch con meno di 7 scelte Dopo i risultati ottenuti dal primo test ci si è chiesti se lo switch fosse sempre più conveniente degli if concatenati, o se fosse dipendente da qualche parametro, come per esempio il numero di if concatenati (e case dello switch). 84

85 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Sono stati quindi rieseguiti i test per load e load2 diminuendo man mano il numero di if (e case), da 7 fino a 1. Nella Tabella 4.4 vengono riportati i valori medi dei tempi di esecuzione. Tabella Tempi di esecuzione if/switch con meno di 7 scelte N if / case Metodo Base Time (s) Cumulative Time (s) load load load load load load load load load load load load load load

86 Cumulative Time (secondi) Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , , load load2 0, , , Numero if / case Figura Grafico andamento Base Time in base al numero di if / case 0, , , , , load load2 0, , Numero if / case Figura Grafico andamento Cumulative Time in base al numero di if / case Analizzando i risultati dei test modificando il numero di if (o case) si può notare come mentre i tempi dello switch rimangono sostanzialmente inalterati (sia per 86

87 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software quanto riguarda il Base Time in Figura 4.3 che il Cumulative Time in Figura 4.4), quelli dell if subiscono una drastica diminuzione quando il numero dei concatenamenti scende a 3, andando ad avvicinarsi molto a quelli sello switch. Scendendo ulteriormente con il numero di concatenamenti, si ottiene che l if risulta più efficiente rispetto allo switch If - switch con più cicli Oltre a valutare l andamento dei tempi di esecuzione in base al numero di if o case, si è pensato di valutare l andamento dei tempi in base al numero di volte che questi costrutti devono essere eseguiti. Nei precedenti test il metodo load esaminava un array contenete 10 oggetti di tipo POInfoColumn. Si è aumentato questo numero, arrivando a 1000 oggetti e valutando man mano le prestazioni dei due metodi (vedi Tabella 4.5). Tabella Tempi di esecuzione in base al numero di POInfoColumn N POInfoColumn Metodo Base Time (s) Cumulative Time (s) load load load load load load load load load load

88 Cumulative Time (secondi) Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , load load2 0, , Numero POInfoColumn Figura Grafico andamento Base Time in base al numero di POInfoColumn 0, , , , , , , load load2 0, , , Numero POInfoColumn Figura Grafico Andamento Cumulative Time in base al numero di POInfoColumn 88

89 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Mentre il Base Time (Figura 4.5) del metodo load è sempre stato inferiore rispetto a quello del metodo load2, i Cumulative Time (Figura 4.6) mostrano dei risultati inaspettati. Si nota infatti che il Cumulative Time del metodo load2 peggiora progressivamente all aumentare del numero di POInfoColumn, mentre il metodo load è più o meno sempre costante. Quando il numero di oggetti presenti nell array superano la quota di 300, il tempo di esecuzione di load2 diventa superiore rispetto a quello del metodo load Cicli for - while Nel primo test riguardante la sostituzione di if concatenati con uno switch, si era utilizzato un ciclo for per valutare gli elementi presenti nell array. Si è pensato di sostituire il ciclo for con un equivalente ciclo while, modificando in questo modo il codice del programma test: Codice Originale (ciclo FOR) Codice Modificato (ciclo While) for (index = 0; index < size; index++) { [ ] while (index < size) { [ ] index++; Si è utilizzato lo stesso programma del primo test, ovvero con 7 if concatenati (o 7 case) e 10 oggetti POInfoColumn nell array. Di seguito i risultati nella Tabella 4.6. Tabella Tempi di esecuzione test for / while N POInfoColumn Metodo Base Time (s) Cumulative Time (s) load load2 For While For While

90 Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione Dai dati rilevati si è notato che la sostituzione del ciclo for con un ciclo while non ha portato ad alcun giovamento. I tempi di esecuzione del metodo con il while sono leggermente peggiorati sia utilizzando gli if concatenati che lo switch, ma comunque sono in linea con i tempi dei metodi con il ciclo for. 4.2 Risultati test sugli iteratori Il secondo gruppo di test ha riguardato l utilizzo degli iteratori in sostituzione al classico ciclo for per la scansione degli oggetti nell array Iteratori con numero valutazioni variabili La sostituzione del ciclo for con un iteratore è stata valutata sul metodo load descritto in precedenza, sia nella sua versione con gli if concatenati che quella con lo switch, per valutare l eventuale influenza del contenuto del ciclo sull iteratore stesso. Tabella Tempi di esecuzione dei metodi con e senza iteratore N POInfoColumn IF / SWITCH IF SWITCH IF SWITCH IF SWITCH Metodo Base Time (s) Cumulative Time (s) load loadit load loadit load loadit load loadit load loadit load loadit

91 Base Time (secondi) Base Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Si è valutato inoltre il cambiamento sui tempi di esecuzione in base al numero di oggetti presenti nell array da scandire. Nella Tabella 4.7 sono stati riportati i valori medi riassuntivi. Nel grafico di Figura 4.7 è possibile evidenziare l andamento del Base Time nei 4 casi. Viene inoltre fornita una versione zoomata della prima parte del grafico (Figura 4.8), ovvero quella relativa ad un numero basso di oggetti nell array. 0, , , , , load - IF load - SWITCH loadit - IF loadit - SWITCH 0, Numero POInfoColumn Figura Grafico Base Time metodo load con e senza iteratori 0, , , , , , load - IF load - SWITCH loadit - IF loadit - SWITCH 0, Numero POInfoColumn Figura Grafico Base Time metodo load con e senza iteratori (zoom) 91

92 Cumulative Time (secondi) Cumulative Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione Nel grafico di Figura 4.9 è evidenziato invece il Cumulative Time nei 4 casi. Subito sotto (Figura 4.10) viene fornita la versione zoomata per la prima parte del grafico. 1, , , , , , , load - IF load - SWITCH loadit - IF loadit - SWITCH 0, , Numero POInfoColumn Figura Grafico Cumulative Time metodo load con e senza iteratori 0, , , , , , , , load - IF load - SWITCH loadit - IF loadit - SWITCH 0, , Numero POInfoColumn Figura Grafico Cumulative Time metodo load con e senza iteratori (zoom) 92

93 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Sia i Cumulative Time che i Base Time forniscono delle informazioni simili sull andamento dei tempi di esecuzione. Si può notare come con un array piccolo (in questo caso composto da 10 oggetti) i due metodi con lo switch risultano nettamente migliori, con tempi cumulativi di un terzo rispetto agli altri. Si nota inoltre che il metodo con l iteratore, inizialmente leggermente inferiore rispetto al metodo classico, si mantiene costante con l aumentare del numero di oggetti nell array, tanto da diventare il metodo migliore di tutti. Come ci si poteva aspettare dati i risultati dei test precedenti, con l aumentare del numero di oggetti i metodi contenenti lo switch peggiorano le prestazioni, ma l uso dell iteratore migliora leggermente le cose. 4.3 Risultati test sulle stringhe Come descritto nel capitolo precedente sono stati effettuati diversi test sulle stringhe. Nei successivi paragrafi vengono riportati tutti i risultati e le considerazioni su questi test Metodo Convert Sono state create 4 versioni del metodo convert e nella Tabella 4.8 vengono riportati i valori medi ottenuti dal test. Sono stati evidenziati in verde i valori migliori, mentre in rosso i valori peggiori. Tabella Tempi di esecuzione metodi convert Metodo Base Time (s) Cumulative Time (s) Convert1 0, , Convert2 0, , Convert3 0, , Convert4 0, ,

94 Cumulative Time (secondi) Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , ,00000 Convert1 Convert2 Convert3 Convert4 Figura Grafico Base Time metodi convert 0, , , , , ,00000 Convert1 Convert2 Convert3 Convert4 Figura Grafico Cumulative Time metodi convert Analizzando i tempi cumulativi (Figura 4.11 e Figura 4.12) si nota come l utilizzo di oggetti di tipo StringBuilder e StringBuffer non ha portato giovamento in questo caso, molto probabilmente perché sono stati utilizzati principalmente metodi come delete e indexof, che rendono meglio con oggetti di tipo String. Questo succede in quanto i metodi in comune tra StringBuilder, StringBuffer e String si riferiscono tutti ai metodi presenti nel tipo String. Se per esempio viene chiamato il metodo indexof 94

95 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software su un oggetto StringBuilder, questo chiama a sua volta lo stesso metodo del tipo String, aumentando quindi il tempo di esecuzione. Da questi dati emerge però anche un altro risultato importante: il metodo con il minor tempo cumulativo è il quarto, ovvero quello che utilizza StringBuffer ma con il preallocamento dello spazio necessario. Si nota quindi quanto è importante questa semplice operazione, che rende il metodo più veloce di quello originale e migliora nettamente le prestazioni rispetto al metodo senza preallocazione (il tempo cumulativo è circa il 25% in meno) Metodo Substring Sono state implementate 6 versioni del metodo substring e nella Tabella 4.9 vengono riportati i valori medi di Base Time e Cumulative Time. Tabella Tempi di esecuzione metodi sub Metodo Base Time (s) Cumulative Time (s) Sub1 0, , Sub2 0, , Sub3 0, , Sub4 0, , Sub5 0, , Sub6 0, ,

96 Cumulative Time (secondi) Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , , , , sub1 sub2 sub3 sub4 sub5 sub6 Figura Grafico Base Time metodi sub 0, , , , , , , , , sub1 sub2 sub3 sub4 sub5 sub6 Figura Grafico Cumulative Time metodi sub 96

97 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Sia considerando il Base Time che il Cumulative Time si nota come il metodo migliore sia il primo, ovvero quello con il classico metodo substring (Figura 4.13 e Figura 4.14). Poco distante si trova il metodo sub6, mentre gli altri, soprattutto sub4 e sub5, sono molto distanti. Il motivo per cui il metodo substring classico è così efficiente si trova nella sua implementazione. Infatti la classe String contiene alcuni attributi privati che permettono di velocizzare le operazioni. Sono presenti per esempio questi attributi: Count, che contiene la lunghezza della stringa. Nei tentativi di implementazioni del metodo substring non è stato possibile accedere a questo attributo se non tramite il metodo length(), il quale introduce ovviamente un certo ritardo. Value, un array che contiene i caratteri presenti nella stringa. Per poter accedere al contenuto della stringa negli altri metodi si è dovuto utilizzare il metodo tochararray(), introducendo ulteriore ritardo. Risulta così evidente il motivo per cui non vale la pena cercare di implementare in maniera differente il metodo substring, a meno di creare un nuovo oggetto contente alcuni attributi privati utili come nell implementazione originale Metodo Substring con diverse dimensioni sottostringa I metodi sub4 e sub5 nel test precedente sono risultati ampiamente i peggiori, data forse la dipendenza del tempo di esecuzione dalla dimensione della sottostringa. Si è pensato quindi di valutare l andamento delle prestazioni alla variazione della lunghezza della sottostringa. In Tabella 4.10 vengono riportati i valori medi. 97

98 Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione Tabella Tempi di esecuzione metodi sub in base alla lunghezza della sottostringa Lunghezza sottostringa Metodo Base Time (s) Cumulative Time (s) Sub1 0, , Sub2 0, , Sub3 0, , Sub4 0, , Sub5 0, , Sub1 0, , Sub2 0, , Sub3 0, , Sub4 0, , Sub5 0, , Sub1 0, , Sub2 0, , Sub3 0, , Sub4 0, , Sub5 0, , Sub1 0, , Sub2 0, , Sub3 0, , Sub4 0, , Sub5 0, ,

99 Base Time (secondi) Base Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 0,030 0,025 0,020 0,015 0,010 0,005 sub1 sub2 sub3 sub4 sub5 0, Lunghezza sottostringa (caratteri) Figura Grafico Base Time metodi sub in base alla lunghezza sottostringa 0, , , , , , , sub1 sub2 sub3 0, , Lunghezza sottostringa (caratteri) Figura Grafico Base Time solo primi 3 metodi sub in base alla lunghezza sottostringa 99

100 Cumulative Time (secondi) Cumulative Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0,070 0,060 0,050 0,040 0,030 0,020 0,010 sub1 sub2 sub3 sub4 sub5 0, Lunghezza sottostringa (caratteri) Figura Grafico Cumulative Time metodi sub in base alla lunghezza sottostringa 0, , , , , ,00005 sub1 sub2 sub3 0, Lunghezza sottostringa (caratteri) Figura Grafico Cumulative Time solo primi 3 metodi sub in base alla lunghezza sottostringa Da queste ulteriori analisi si evidenzia come i metodi sub4 e sub5 siano profondamente influenzati dal numero di caratteri della sottostringa (Figura 4.15 e Figura 4.17). Mentre con pochi caratteri hanno tempi compatibili con gli altri metodi, 100

101 Base Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software già con 10 caratteri diventano decisamente peggiori. Gli altri 3 metodi mantengono dei tempi di esecuzione abbastanza costanti (Figura 4.16 e Figura 4.18). In questo test non è stato preso in considerazione il metodo sub6 del test precedente in quanto molto simile al metodo sub Concatenamento di stringhe In questo test si è considerata l ipotesi di sostituire il classico concatenamento tra stringhe con il simbolo + con metodi alternativi che utilizzano gli oggetti di tipo StringBuilder e StringBuffer. In Tabella 4.11 sono riportati i risultati medi dei tempi di esecuzione dei 3 metodi alternativi. Tabella Tempi di esecuzione metodi concatenamento Metodo Base Time (s) Cumulative Time (s) Metodo1 (+) 0, , Metodo2 (StringBuffer) 0, , Metodo1 (StringBuilder) 0, , , , , , , , , ,00000 Metodo1 Metodo2 Metodo3 Figura Grafico Base Time metodi concatenamento stringhe 101

102 Cumulative Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , , ,00000 Metodo1 Metodo2 Metodo3 Figura Grafico Cumulative Time metodi concatenamento stringhe Come si può vedere dai grafici di Figura 4.19 e Figura 4.20 i metodi alternativi che utilizzano StringBuilder e StringBuffer si sono dimostrati migliori rispetto a quello classico. Tra questi due il tempo minore è stato segnato dal metodo3, ovvero quello che utilizza StringBuilder Concatenamento di stringhe con attributi statici Si è effettuata un altra versione del test precedente utilizzando degli attributi statici definiti all esterno dei metodi, in modo da lasciare all interno solo ed esclusivamente il concatenamento. In questo modo i tempi dovrebbero essere più verosimili. In Tabella 4.12 sono riportati i valori medi dei tempi di esecuzione. Tabella 4.12 Tempi di esecuzione metodi concatenamento con attributi statici Metodo Base Time (s) Cumulative Time (s) Metodo1 (+) 0, , Metodo2 (StringBuffer) 0, , Metodo1 (StringBuilder) 0, ,

103 Cumulative Time (secondi) Base Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 0, , , , , , , Metodo1 Metodo2 Metodo3 Figura Grafico Base Time metodi concatenamento con attributi statici 0, , , , , , , , , Metodo1 Metodo2 Metodo3 Figura Grafico Cumulative Time metodi concatenamento con attributi statici I due metodi alternativi fanno segnare tempi decisamente migliori rispetto a quello originale anche in questo test. Tra i due il metodo3 risulta avere il tempo di esecuzione più basso, quasi la metà di quello originale (Figura 4.21 e Figura 4.22). 103

104 Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione Risultati test sui metodi generici Vengono ora riportati i risultati degli ultimi test sulle stringhe riguardante alcuni metodi generici. Si è valutato il comportamento a seconda dell oggetto su cui erano chiamati, ovvero String, StringBuffer o StringBuilder. Nella Tabella 4.13 sono riportati i dati relativi al metodo charat, riassunti dai grafici di Figura 4.23 e Figura Tabella Tempi di esecuzione metodo charat Metodo Base Time (s) Cumulative Time (s) charat (string) 0, , charat (StringBuffer) 0, , charat (StringBuilder) 0, , , , , , , , , charat (String) charat (StringBuffer) charat (StringBuilder) Figura Grafico Base Time metodo charat 104

105 Cumulative Time (secondi) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 0, , , , , , charat (String) charat (StringBuffer) charat (StringBuilder) Figura Grafico Cumulative Time metodo charat Nella Tabella 4.14 e nei grafici di Figura 4.25 e Figura 4.26 sono riportati i risultati dei test sul metodo getchars. Tabella Tempi di esecuzione metodo getchars Metodo Base Time (s) Cumulative Time (s) getchars (string) 0, , getchars (StringBuffer) 0, , getchars (StringBuilder) 0, ,

106 Cumulative Time (secondi) Base Time (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , , , getchars (String) getchars (StringBuffer) getchars (StringBuilder) Figura Grafico Base Time metodo getchars 0, , , , , , getchars (String) getchars (StringBuffer) getchars (StringBuilder) Figura Grafico Cumulative Time metodo getchars Dai risultati ottenuti si evince come l utilizzo di questi metodo su oggetti di tipo StringBuffer e StringBuilder porti ad un aumento del tempo di esecuzione. 106

107 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Riguardo al metodo charat il metodo peggiore si è rivelato essere quello utilizzato con il tipo StringBuilder, con un tempo cumulativo triplo rispetto a quello chiamato su un oggetto String. Riguardo invece al metodo getchars il metodo peggiore è stato quello con il tipo StringBuffer, con un tempo cumulativo quasi triplo rispetto a quello con il classico tipo String. 4.4 Risultati test programma ad hoc L ultimo test per valutare i tempi di esecuzione è stato eseguito su un programma ad hoc, che riunisse tutte le problematiche viste finora. Nella Tabella 4.15 vengono riportati i tempi cumulativi e di utilizzo di CPU riferiti al metodo load e la sua versione migliorata loadmod, con il supporto del grafico di Figura Nella Tabella 4.17 vengono invece riportati i tempi cumulativi e di utilizzo di CPU dell intero programma. Con MainAsis si è indicato il main del programma di partenza e con MainMod il main del programma modificato. Il grafico di Figura 4.28 riassume i dati globali dei tempi di esecuzione dei main dei due programmi. Tabella Tempi di esecuzione metodo load e loadmod Metodo Cumulative Time (s) CPU Time (s) load loadmod

108 Tempo esecuzione (secondi) Tempo esecuzione (secondi) Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione 0, , , , , , , Load LoadMod 0, , , Cumulative Time CPU Time Figura Grafico Cumulative e CPU Time metodi load Tabella Tempi di esecuzione MainAsIs e MainMod Metodo Cumulative Time (s) CPU Time (s) MainAsis MainMod , , , , , , MainAsis MainMod 0, , , Cumulative Time CPU Time Figura Grafico Cumulative e CPU Time globali 108

109 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Considerando i tempi dei metodi load si nota come ci sia un notevole miglioramento delle prestazioni; il tempo cumulativo del metodo modificato è meno di un settimo rispetto all originale. Valutando i tempi totali si osserva che il tempo cumulativo del programma modificato è praticamente un terzo rispetto a quello originale. Il sostanzioso vantaggio ottenuto dal metodo load modificato viene in parte ridotto a livello globale a causa di tutto ciò che è esterno al metodo, cioè costruttori, dichiarazione di variabili, chiamate ad altri metodi, che sono comuni a tutte e due le versioni. 4.5 Regole di ottimizzazione Dall analisi di tutti questi test si possono estrapolare alcune regole che permettano un ottimizzazione delle prestazioni dei programmi Java. Grazie ai test su cicli e if concatenati si è notato quanto un costrutto come lo switch possa essere di grande aiuto e come migliori nettamente le prestazioni. Come evidenziato bene dal grafico di Figura 4.3, il tempo di esecuzione dello switch risulta essere nettamente più basso già con soli 3 if concatenati. Si può quindi affermare che è preferibile utilizzare uno switch in sostituzione di 3 o più if concatenati. C è però da fare attenzione, in quanto lo switch perde progressivamente vantaggio quando viene ripetuto diverse volte. Dai test è emerso che nel caso lo switch fosse all interno di un ciclo, è preferibile solo se viene ripetuto meno di 300 volte. Non si ha invece nessun guadagno di prestazioni con la sostituzione di un ciclo for con un ciclo while. Dai dati emersi dall analisi degli iteratori su può dire che l utilizzo di questi costrutti è evidentemente legato al numero di oggetti su cui devono lavorare. Si può quindi dire che se il numero di oggetti presenti nella lista (array o vettore) da valutare non è troppo basso (superiore a 10-20), l iteratore porta un miglioramento delle 109

110 Marco Lui Capitolo 4 - Risultati e regole di ottimizzazione prestazioni. Il vantaggio aumenta progressivamente con l aumentare del numero di oggetti da valutare. Dato che l iteratore ha un costo di implementazione fisso, si avrà vantaggio quando le operazioni fatte su ogni oggetto sono numerose o dispendiose, in modo da ammortizzare il costo iniziale. Se non è noto a priori il numero di oggetti da valutare con l iteratore, oppure il numero potrebbe essere molto variabile, si potrebbe utilizzare questa soluzione: implementare un metodo che utilizza l iteratore e uno classico con un ciclo for. La scelta del metodo da utilizzare potrebbe essere fatta in base alla dimensione dell array o del vettore da scandire. Per quanto riguarda i test sulle stringhe si può dire come l utilizzo di tipi alternativi come StringBuilder e StringBuffer possano portare delle notevoli migliorie. Nello specifico sono preferibili quando vi è necessità di manipolare le stringhe con operazioni come cancellazioni, sostituzioni di caratteri con altri e concatenamenti. In caso contrario non vi è vantaggio. Si è notato inoltre che il preallocamento al momento della creazione della variabile di tipo StringBuilder e StringBuffer migliora notevolmente le prestazioni ed è vivamente consigliato (quando possibile). Si noti come non sono state trovate delle regole assolute, che vadano bene in qualsiasi contesto, ma solo regole che dipendono dalle condizioni al contorno. Sarà quindi onere del programmatore valutare caso per caso la possibilità di applicare le regole empiriche trovate. Nella Tabella 4.17 vengono riassunte le regole trovate. 110

111 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software Tabella Riassunto regole di ottimizzazione energetica Tipologia Regola Risparmio Tempo If / Switch Iteratori Stringhe Stringhe Sostituire 3 o più if concatenati con uno switch, a patto che non sia all interno di un ciclo con più di 300 iterazioni Sostituire un ciclo for con un iteratore se si valutano almeno oggetti in una lista. Più operazioni vengono fatte nel ciclo e più è conveniente l iteratore. Sostituire il concatenamento di più stringhe effettuato con il simbolo + con la creazione di un oggetto StringBuilder con preallocamento e utilizzo del metodo append. Sostituzione di oggetti stringa con oggetti del tipo StringBuilder e StringBuffer, con preallocamento dello spazio, quando si devono effettuare manipolazioni come cancellazioni o sostituzioni di caratteri. Fino a 78% Dal 15% (1000 cicli) al 65% (10mila cicli) Fino al 42% Risparmio dipendente dal tipo di operazioni eseguite. 111

112 Capitolo 5 5 Validazione empirica dei risultati Nel Capitolo 4 sono stati presentati tutti i dati risultanti dai test effettuati e da questi sono state estrapolate alcune regole di ottimizzazione. Seguire queste indicazione dovrebbe portare a creare programmi con un tempo di esecuzione inferiore alla norma. Questo però non comporta in maniera automatica un risparmio energetico. Viene naturale pensare che un programma che impieghi meno tempo per essere eseguito consumi anche meno energia. In realtà non esiste una correlazione così forte, anche se un minor tempo di esecuzione molto probabilmente avrà effetti positivi sul consumo energetico. Potrebbe capitare infatti che un metodo con un tempo di esecuzione inferiore abbia necessità di più energia perché impegnato in operazioni molto più CPU intensive rispetto agli altri metodi. Potrebbe altresì succedere che un programma A con la metà del tempo di esecuzione di un altro programma B consumi meno della metà dell energia, in quanto oltre ad avere un risparmio temporale potrebbe utilizzare metodi meno CPU intensive. Si è reso quindi necessario validare i risultati ottenuti con i test sui tempi di esecuzione con dei test energetici eseguiti in laboratorio. Il computer utilizzato per questi test era un eserver IBM x3500 con le seguenti caratteristiche: 112

113 Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software 2 processori Intel Xeon Quad-core 3.00 GHz (12 MB L2 cache), FSB a 1333 MHz. Memoria di sistema 17GB PC DDR2 SDRAM. Sistema Operativo Microsoft Windows 2007 Server Enterprise. Prima di procedere con i test è stata valutata la potenza media dell idle, controllando più volte il valore e mediando i risultati. La potenza media di idle, che verrà usata in tutti i test, è risultata W. 5.1 Validazione regole if - switch Il primo test energetico ha riguardato la sostituzione di if concatenati con uno switch equivalente. Il numero di concatenamenti è 7, mentre il numero di oggetti da valutare (ovvero il numero di POInfoColumn) è 10. All interno degli if e dei case non sono eseguite istruzioni ed il metodo contenente gli if o switch è stato ripetuto 100 milioni di volte per avere tempi di esecuzione più lunghi e facilmente percepibili. Nella Tabella 5.1 sono riportati: Il tempo di esecuzione, restituito direttamente dal programma di acquisizione. L energia effettiva del programma, calcolata come differenza tra energia totale e quella dell idle nello stesso tempo, anch essa restituita direttamente dal programma di acquisizione. Il tempo effettivo, ottenuto tenendo conto solo del tempo in cui la potenza istantanea era nettamente superiore ai valori di idle (indicazione sull effettiva esecuzione in quell istante del programma test). I valori riportati nella Tabella 5.1 sono ottenuti dalla media di 5 ripetizioni e controllando sempre la bontà della confidenza. Tabella Dati test energetico su if/switch Metodo Tempo esecuzione (s) Energia effettiva (J) Tempo effettivo (s) IF SWITCH

114 Energia effettiva (J) Tempo effettivo (secondi) Marco Lui Capitolo 5 - Validazione empirica dei risultati Risparmio energetico: 47.3 % Risparmio tempo: 52.5 % 4,500 4,000 3,500 3,000 2,500 2,000 1,500 1,000 0,500 0,000 IF SWITCH Figura Grafico tempo effettivo if/switch IF SWITCH Figura Grafico energia effettiva if/switch 114

115 Potenza Istantanea (W) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software IF SWITCH Figura Grafico andamento Potenze istantanee nel tempo Nel grafico di Figura 5.3 sono riportati gli andamenti della potenza istantanea nei due casi. I valori presenti sull ascissa indicano la numerazione dei campioni. L intervallo di tempo tra due campioni si aggira intorno a 0.25 secondi. Per quanto riguarda la sostituzione degli if concatenati con uno switch si ha praticamente un dimezzamento sia del tempo di esecuzione che di energia spesa. Ciò indica una notevole correlazione tra i due tipi di risparmio, dato anche dal fatto che i valori di potenza immediata sono pressoché uguali. Dai dati ottenuti con i test temporali si era evidenziato come lo switch avesse dei tempi di esecuzione di un terzo rispetto agli if. Il dato qui ottenuto è leggermente inferiore, ma c è da considerare che: L energia è riferita all esecuzione di tutto il programma, non solo al singolo metodo contenente lo switch. La ripetizione del metodo un così gran numero di volte porta un certo dispendio energetico comune a tutti e due i tipi di metodo per la gestione delle classi, chiamate dei metodi, costruttori ecc 115

116 Tempo effettivo (secondi) Marco Lui Capitolo 5 - Validazione empirica dei risultati 5.2 Validazione programma ad hoc Il secondo test energetico si è focalizzato sul programma creato ad hoc per testare tutte le migliorie trovate. Per allungare i tempi di esecuzione, i programmi AS-IS e MOD lanciano 1 milione di volte il metodo load contenente la valutazione dei 10 oggetti di tipo POInfoColumn presenti nell array (o vettore). Come sempre sono state effettuate 5 ripetizioni e i valori medi sono riportati in Tabella 5.2. Tabella Dati test energetico programma ad hoc Programma Tempo esecuzione (s) Energia (J) Tempo effettivo (s) AS-IS MOD Risparmio energetico: % Risparmio tempo: % AS-IS MOD Figura Grafico tempo effettivo programma ad hoc 116

117 Potenza Istantanea (W) Energia effettiva (J) Definizione e validazione sperimentale di regole di scrittura del codice per ottimizzare l efficienza energetica del software AS-IS MOD Figura Grafico energia effettiva programma ad hoc AS - IS MOD Figura Grafico andamento Potenze istantanee nel tempo Dai dati sui tempi di esecuzione del programma ad hoc eseguiti precedentemente si era ottenuto che il programma modificato impiegava solo un terzo del tempo impiegato dal programma AS-IS, ovvero un risparmio del 67%. 117