Note di sviluppo Applet 3DEnter

Transcript

1 Note di sviluppo Applet 3DEnter Ronny Meoli Roberto Nunnari Andrea Scolari Autore 9 luglio 2004 Indice 1 Introduzione 1 2 Finite State Machine User FSM World FSM Gestione Hashtable Hashtable Object Pooling Camera Design Implementazione PortableFloat Implementazione Uso A Diagramma dei package 10 B Analisi della performance 10 B.1 Modalità dei test B.2 Test B.2.1 Percorso eseguito B.2.2 Analisi dei risultati B.3 Test B.3.1 Descrizione del test B.3.2 Analisi dei risultati Introduzione In questo documento vengono descritti i maggiori cambiamenti alla struttura dell'applet. 1

2 2 Finite State Machine Per migliorare la performance del sistema di controllo dell'applet, sono state introdotte due Finite State Machine: una che controlla le azioni dell'utente (User) e una che controlla il sistema (World). Esse sono posizionate in cascata in modo tale che le azioni dell'utente gestite dalla User FSM vengano passate alla World FSM, la quale esegue poi le azioni nali. Le stesse gestiscono poi dei task asincroni tramite delle funzioni di callback, p.es. il movimento della camera. Il generatore utilizzato si chiama Nunni FSM Gen, progetto opensource consultabile su NunniFSMGen generates a FSM (Finite State Machine) in Java, C or C++ starting from a transition table. NunniFSMGen cleanly separates logic from implementation by using a modied version of the state pattern, easing the development process! 2.1 User FSM In gura 1 è rappresentato un diagramma semplicato delle classi del package ch.denter.controller.user. Figura 1: Outline User FMS 2.2 World FSM In gura 2 è rappresentato un diagramma semplicato delle classi del package ch.denter.controller.world. 3 Gestione Hashtable Nella classe WorldData vengono usati dei Vector per memorizzare i vari elementi che compongono la scena 3D. Durante l'esecuzione dell'applet, questi 2

3 Figura 2: Outline World FMS elementi devono essere modicati molto spesso. La ricerca dell'elemento desiderato viene eettuata con un ciclo for e degli if: questa tecnica ha una complessità computazionale molto alta e necessita di essere migliorata. 3.1 Hashtable Per risolvere il problema si è pensato di usare delle Hashtable al posto dei Vector. Infatti sono molto più performanti e permettono di ottenere l'oggetto memorizzato semplicemente usando una chiave che lo identichi. Da una attenta analisi dei metodi di accesso ai componenti dei vari Vector, è stato possibile identicare 4 metodi di ricerca, illustrati in tabella 1. Per ogni metodo di accesso è stata creata una classe che verrà usata come chiave nella rispettiva Hashtable. Nome classe AnfyKeyOne AnfyKeyTwo IntegerKey ReplElementsKey Tabella 1: Classi-chiave Criterio di richiesta idobj, subid idelem Numero intero col1dis, col2dis, col3dis, idclip, idimm L'implementazione è molto semplice. Per ogni classe creata, si è denito come attributi privati i criteri di richiesta esposti precedentemente. In più si è anche ridenito i metodi equals() e hashcode(), per permettere la comparazione di oggetti solamente tra i rispettivi attributi di classe. Ogni oggetto-chiave così creato ha anche un numero seriale, gestito dalla classe astratta GenericKey. L'introduzione di questo numero seriale è stato necessario in quanto possono esistere due oggetti-chiavi con identici valori degli attributi. Il numero seriale permette così di distinguere tutti gli oggetti-chiave in modo univoco. In gura 3 è rappresentato il diagramma delle classi del package ch.denter. keydistrib.key. 3

4 Figura 3: Diagramma delle classi, package ch.denter.keydistrib.key 4

5 3.2 Object Pooling Gli scopi principali del Refactoring dell'applicazione comprendevano il miglioramento delle performance generali e la diminuzione del consumo di memoria in runtime. Adottando la tecnica delle chiavi esposta nella sezione precedente, si è notato che per ogni operazione di get e set sulle Hashtable, viene creato ogni volta un nuovo oggetto chiave. Si sa che le operazioni di creazione di nuovi oggetti richiedono molte risorse, soprattutto se eettuate molto spesso durante l'esecuzione dell'applicazione. Per ovviare a questo problema, è stato sviluppato un sistema di Object pooling. Object pooling allows the sharing of instantiated objects. Since dierent processes don't need to reinstantiate certain objects, there is no load time. And since the objects are returned to the pool, there is a reduction in garbage collection. L'implementazione è basata su una classe statica StaticDistributor, illustrata in gura 4. Essa contiene tutti i riferimenti ai vari pool di oggetti delle chiavi, richiamabili tramite il metodo getdistributor(int). Figura 4: Diagramma delle classi, package ch.denter.keydistrib La gestione dei pool avviene nel package ch.denter.keydistrib.pooling, illustrato in gura 5. La classe astratta KeyPool si occupa di gestire tutti i pool, mentre la classe CleanUpThread elimina gli oggetti non più utilizzati. 4 Camera L'implementazione originale della Camera è stata realizzata in due classi, Camera e CameraAuto. Questo design presenta diversi problemi, tra cui: Struttura non adatta alla complessità delle operazioni svolte Struttura non adatta alla complessità della camera Struttura non adatta per il numero di operazioni svolte Troppi operatori condizionali, che obbligano il sistema a controlli inutili L'aggiunta di nuove funzionalità comporta la revisione di tutte le altre funzionalità implementate 5

6 Figura 5: Diagramma delle classi, package ch.denter.keydistrib.pooling 6

7 4.1 Design La nuova struttura della camera è stata ridisegnata completamente in modo da: Poter aggiungere nuove funzionalità Rendere il sistema nalmente stabile Aumentare la essibilità della telecamera Rendere il lavoro di manutenzione più facile Facilitare la congurazione della camera rispetto alla tipologia dello scenario Poter costruire una libreria di algoritmi di spostamento da aggiungere o togliere facilmente (tipo plug-in) Aumentare la performance dell'intero sistema In gura 6 è rappresentato un diagramma semplicato della nuova struttura della camera. Figura 6: Outline nuova struttura camera La descrizione dei vari elementi è riportata in tabella 2. Tabella 2: Descrizione struttura camera Nome classe Descrizione Camera È la classe principale, la camera viene controllata attraverso i suoi metodi. CameraModality È una classe astratta che denisce i metodi da implementare dalle varie modalità Modalityn Le varie modalità 7

8 4.2 Implementazione L'implementazione nale non dierisce molto dall'outline presentato prima. Come visibile in gura 7, è stata aggiunta una classe CameraBean che contiene tutte le variabili della camera, e un classe CameraAuto che gestisce i cambiamenti di direzione durante l'avanzamento automatico. L'interazione con il sistema avviene sempre tramite la classe Camera. Figura 7: Struttura nale della camera 5 PortableFloat La maggior parte dei device J2ME non supporta l'uso dei numeri oating point. Si è scelto quindi di implementare una libreria che usa Fixed Point Math. 5.1 Implementazione I valori Fixed Point vengono memorizzati nel tipo nativo long di Java. Ogni numero consiste di due parti: una parte intera negli ultimi 35 bit e di una parte frazionaria nei primi 29 bit. La parte frazionaria è espressa in 2 29 esimi. Un numero Fixed Point dev'essere costruito secondo la regola esposta nell'equazione 1. ± ((i << 29) f) (1) Dove i è la parte intera e f è la parte frazionaria. Per esempio i due valori e diventerebbero: 5.2 Uso ((7 << 29) ), = ((3 << 29) ), = In gura 8 è rapppresentato il diagramma delle classi del package ch.supsi.fpmath. PortableFloat è una classe astratta che denisce delle costanti poat dei metodi in comune come tofp(), che permette di convertire un numero intero o una stringa (p.es ) in poat. Le altre due classi implementano 8

9 Figura 8: Diagramma delle classi package ch.supsi.fpmath 9

10 i vari metodi matematici. PortableFloatA converte i poat in oat per fare i calcoli e ritorna il risultato in ploat. PortableFloatB usa invece solo poat nei calcoli. Le operazioni aritmetiche somma (+) e sottrazione ( ), l'operatore unario di negazione ( ) e gli operatori di confronto (==, <, <=, >, >=) si possono usare direttamente. Per quanto riguarda moltiplicazione, divisione,... bisogna usare i metodi deniti in PortableFloat. A Diagramma dei package In gura 9 è riportato il diagramma dei package dell'applet alla ne del processo di refactoring. B Analisi della performance Per vericare se il nuovo sistema di gestione delle chiavi è performante, sono stati eseguiti dei test sull'applicazione con un tool di proling. B.1 Modalità dei test Sono stati eseguiti 2 test con e senza la gestione delle chiavi: 1. Test complessivo: monitoraggio del consumo di memoria dell'applet lungo un percorso prestabilito; 2. Test specico: la gestione delle chiavi è stata isolata dal resto del programma ed è stato monitorato il consumo di memoria e la velocità di esecuzione. B.2 Test 1 B.2.1 Percorso eseguito 1. Entrata labirinto 2. Sezione libri 3. Scelta del genere (I scaale) 4. Avanzamento automatico nella galleria no alla ne dei libri 6. Stop della telecamera 7. Ritorno indietro no alla ne dei libri 9. Stop della telecamera 10. Clic su box info e ritorno al labirinto 10

11 Figura 9: Diagramma dei package 11

12 B.2.2 Analisi dei risultati Come visibile dai graci illustrati in gura 10 e 11, il consumo di memoria eettivo risulta minore nella versione con le chiavi. Questo è dovuto presumibilmente al fatto che i pool che gestiscono le chiavi eliminano gli oggetti non più utilizzati, liberando memoria. Anche il tempo di esecuzione totale del percorso risulta di 30 s minore nella versione con le chiavi. Gli intervalli di tempo da prendere in considerazione sono: 4-5, 7-8. Le prove sono ripetibili e si ottengono sempre risultati simili. Un unico problema inuisce sulle performance totali: il tempo di latenza e di download dei dati da Internet. Per ovviare a questo problema è stato eseguito un secondo Test. B.3 Test 2 B.3.1 Descrizione del test Per poter eseguire questo test, sono state implementate delle classi di testbenchmarking, riportate a pagina 12. Queste classi simulano l'uso dei metodi di add-get della classe WorldData. Per poter eettuare un test veritiero, è stato necessario ottenere dei dati di utilizzo di queste classi, ovvero quante volte i dati vengono letti-scritti con i metodi di add-get. Questi dati sono poi stati inclusi nella classe Benchmark: come si può vedere dal codice, sono stati presi 10 valori per ogni Hashtable e per ogni operazione su di essi (scrittura-lettura). Il test viene poi eseguito 100 volte dalla classe Test, monitorando il consumo di memoria e il tempo medio di esecuzione di ogni blocco di scrittura-lettura. /* * Benchmark.java * */ package ch.denter.util.bench; import ch.denter.data.p13elemento; import ch.denter.data.p13elementoanfy; import ch.denter.data.p13immagine; import ch.denter.generatore.stored_3dworld_data; import java.util.vector; /** * Andrea */ public class Benchmark { private int[] _anfytimesread = {38,115,46,144,129,149,69,243,170,150; private int[] _anfytimeswrite = {141,126,193,143,157,143,189,443,144,143; private int[] _movementtimesread = {2,3,5,5,5,6,4,3,2,5; 12

13 Figura 10: Risultati Test 1: con Vector 13

14 Figura 11: Risultati Test 1: con Hashtable e chiavi 14

15 private int[] _movementtimeswrite = {118,56,96,73,78,73,92,420,62,73; private int[] _imagestimesread = {7,1,17,12,11,12,13,9,1,12; private int[] _imagestimeswrite = {7,1,11,9,7,9,7,7,1,9; public void testanfy(int i) { P13ElementoAnfy ele; //write for (int j=0;j<_anfytimeswrite.length;j++) { for (int k=0;k<_anfytimeswrite[j];k++) { ele = new P13ElementoAnfy(); ele.setidobjanfy(i); ele.setsubid(j); ele.setidelemento(k); Stored_3DWorld_Data.add_Data_To_VettoreAnfy(ele); ele = null; //read for (int j=0;j<_anfytimesread.length;j++) { for (int k=0;k<_anfytimesread[j];k++) { int temp = Stored_3DWorld_Data.getIdElemento(i,j); public void testimages(int i) { P13Immagine ele; //write for (int j=0;j<_imagestimeswrite.length;j++) { for (int k=0;k<_imagestimeswrite[j];k++) { ele = new P13Immagine(); ele.setidimmagine(i+j+k); Stored_3DWorld_Data.add_Image_To_Vettore(ele); ele = null; //read for (int j=0;j<_imagestimesread.length;j++) { for (int k=0;k<_imagestimesread[j];k++) { ele = Stored_3DWorld_Data.getImmagine(i+j+k); ele = null; 15

16 public void testmov(int i) { P13Elemento ele; //write for (int j=0;j<_movementtimeswrite.length;j++) { for (int k=0;k<_movementtimeswrite[j];k++) { ele = new P13Elemento(); ele.setidelemento(i+j+k); Stored_3DWorld_Data.add_Data_To_Vettore_EleMovimento(ele); ele = null; //read for (int j=0;j<_movementtimesread.length;j++) { for (int k=0;k<_movementtimesread[j];k++) { ele = Stored_3DWorld_Data.getP13Elemento(i+j+k); ele = null; /* * Test.java * */ package ch.denter.util.bench; import ch.denter.data.p13elemento; import ch.denter.data.p13elementoanfy; import ch.denter.data.p13immagine; import ch.denter.generatore.stored_3dworld_data; import java.util.vector; /** * Andrea */ public class Test { /** args the command line arguments */ public static void main(string[] args) { 16

17 Benchmark b = new Benchmark(); int sumanfy = 0; int sumimages = 0; int summov = 0; int times = 100; for (int i=0;i<times;i++) { //System.out.println("anfy"+i); long start = System.currentTimeMillis(); b.testanfy(i); long stop = System.currentTimeMillis(); //System.out.println("Test " + i + ": " + (stop-start)); sumanfy += (int)(stop-start); //System.out.println("images"+i); start = System.currentTimeMillis(); b.testimages(i); stop = System.currentTimeMillis(); //System.out.println("Test " + i + ": " + (stop-start)); sumimages += (int)(stop-start); //System.out.println("mov"+i); start = System.currentTimeMillis(); b.testmov(i); stop = System.currentTimeMillis(); //System.out.println("Test " + i + ": " + (stop-start)); summov += (int)(stop-start); //System.out.println("remove"+i); Stored_3DWorld_Data.remove_All_Data_Structures(); System.gc(); System.out.println("Average Anfy : " + (sumanfy/times)); System.out.println("Average Images: " + (sumimages/times)); System.out.println("Average Mov : " + (summov/times)); System.exit(0); B.3.2 Analisi dei risultati Nelle tabelle 3 e 4 sono illustrati i risultati del Test 2.1 Velocità di esecuzione. Il metodo con le chiavi sembra essere più veloce quando il numero di elementi è grande. Se si guarda il risultato del Test 2.1 globalmente, le chiavi portano a un dimezzamento sicuro del tempo di esecuzione di operazioni di add-get in WorldData. Nelle gure 12 e 13 sono illustrati i risultati del Test 2.2 Consumo di memoria. Come si poteva prevedere, il consumo di memoria è leggermente maggiore con le chiavi. Questo è dovuto all'overhead di memoria per memorizzare gli 17

18 Tabella 3: Velocità di esecuzione con Vector Average (ms) Test Anfy Images Mov Min Ave Max Std Dev Tabella 4: Velocità di esecuzione con Hashtable Average (ms) Test Anfy Images Mov Min Ave Max Std Dev

19 Figura 12: Risultati Test 2: con Vector 19

20 Figura 13: Risultati Test 2: con Hashtable 20

21 oggetti nel pool. Però è più eciente rispetto al metodo con i Vector in quanto gli oggetti non più utilizzati vengono eliminati periodicamente da un thread di pulizia. 21