Analisi di prestazione dell’interprete tuProlog supiattaforma Java

Michele Damian

ALMA MATER STUDIORUM - UNIVERSITA DI BOLOGNA

Facolta di Ingegneria

Corso di Laurea Triennale in Ingegneria Informatica

Relatore: Chiar.mo Prof. Enrico Denti

Anno Accademico 2007/2008

19 marzo 2009

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Obiettivi

Obiettivi

Porre delle basi utili per il miglioramento delle prestazioni di tuProlog.

Attraverso l’analisi dei tempi di esecuzione. . .

e attraverso l’analisi dell’utilizzo della memoria.

Confrontare le performance delle versioni 2.1 e 1.3 dell’interprete.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Obiettivi

Obiettivi

Porre delle basi utili per il miglioramento delle prestazioni di tuProlog.

Attraverso l’analisi dei tempi di esecuzione. . .

e attraverso l’analisi dell’utilizzo della memoria.

Confrontare le performance delle versioni 2.1 e 1.3 dell’interprete.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Obiettivi

Obiettivi

Porre delle basi utili per il miglioramento delle prestazioni di tuProlog.

Attraverso l’analisi dei tempi di esecuzione. . .

e attraverso l’analisi dell’utilizzo della memoria.

Confrontare le performance delle versioni 2.1 e 1.3 dell’interprete.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Obiettivi

Obiettivi

Porre delle basi utili per il miglioramento delle prestazioni di tuProlog.

Attraverso l’analisi dei tempi di esecuzione. . .

e attraverso l’analisi dell’utilizzo della memoria.

Confrontare le performance delle versioni 2.1 e 1.3 dell’interprete.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

L’interprete tuProlog

L’interprete tuProlog

Interprete per il linguaggio di programmazione logica Prolog, ideato percreare componenti in un’infrastruttura internet dinamica.

Caratteristiche principali

Scritto interamente in Java.

Interoperabile con le librerie Java.

Portabile.

Leggero.

Configurabile.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Teorie di test

Parte del benchmark e composto da teorie utilizzate precedentementeper confrontare le prestazioni di tuProlog con altri interpreti Prolog.

Al fine di rispecchiare maggiormente l’utilizzo di tuProlog su sistemidi calcolo moderni il benchmark e stato completato con nuove teorieche aumentano il carico di lavoro.

Altre teorie sono state scritte per analizzare in modo adeguato lascalabilita delle prestazioni del motore confrontando il numero di statidell’albero di ricerca della soluzione con i tempi di esecuzione.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Teorie di test

Parte del benchmark e composto da teorie utilizzate precedentementeper confrontare le prestazioni di tuProlog con altri interpreti Prolog.

Al fine di rispecchiare maggiormente l’utilizzo di tuProlog su sistemidi calcolo moderni il benchmark e stato completato con nuove teorieche aumentano il carico di lavoro.

Altre teorie sono state scritte per analizzare in modo adeguato lascalabilita delle prestazioni del motore confrontando il numero di statidell’albero di ricerca della soluzione con i tempi di esecuzione.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Teorie di test

Parte del benchmark e composto da teorie utilizzate precedentementeper confrontare le prestazioni di tuProlog con altri interpreti Prolog.

Al fine di rispecchiare maggiormente l’utilizzo di tuProlog su sistemidi calcolo moderni il benchmark e stato completato con nuove teorieche aumentano il carico di lavoro.

Altre teorie sono state scritte per analizzare in modo adeguato lascalabilita delle prestazioni del motore confrontando il numero di statidell’albero di ricerca della soluzione con i tempi di esecuzione.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Benchmark

Il profiler HPROF

E uno strumento per il profiling di applicazioni Java in grado di iniettarebytecode nel codice da eseguire.

Pregi

Essendo distribuito liberamente nel JDK e facilmente accessibile perfuture estensioni del lavoro.

Consente l’analisi dei tempi di esecuzione e dell’utilizzo della memoria.

Permette un’analisi classe per classe e metodo per metodo.

Mostra il trace dello stack che ha generato la chiamata ad un metodoo una allocazione.

Difetti

Misura in modo errato il numero di oggetti live allocati, mostrando glioggetti non ancora garbage collected.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Scalabilita

3 + 6! stati 248 sStruct.unify 1947041Var.unify 2584249Var.free 18025053 + 2 ∗ 6! stati 489 sStruct.unify 3876572Var.unify 5181011Var.free 36017503 + 3 ∗ 6! stati 1898 sObject.wait 2ReferenceQueue.remove 4Struct.unify 5813154Var.unify 7768221Var.free 5398379

Sono stati analizzati i tempi diesecuzione per risoluzioni di obiettivisempre piu complessi.

La funzione (tempo diesecuzione)/(numero di stati) e lineareper obiettivi semplici.

Ma per obiettivi piu complessi leprestazioni degradano.

Anche il numero delle chiamate aimetodi e proporzionale al numerodegli stati.

I metodi Object.wait eReferenceQueue.remove chiamati dalGarbage Collector sono fra le causeprincipali del degrado.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Scalabilita

3 + 6! stati 248 sStruct.unify 1947041Var.unify 2584249Var.free 18025053 + 2 ∗ 6! stati 489 sStruct.unify 3876572Var.unify 5181011Var.free 36017503 + 3 ∗ 6! stati 1898 sObject.wait 2ReferenceQueue.remove 4Struct.unify 5813154Var.unify 7768221Var.free 5398379

Sono stati analizzati i tempi diesecuzione per risoluzioni di obiettivisempre piu complessi.

La funzione (tempo diesecuzione)/(numero di stati) e lineareper obiettivi semplici.

Ma per obiettivi piu complessi leprestazioni degradano.

Anche il numero delle chiamate aimetodi e proporzionale al numerodegli stati.

I metodi Object.wait eReferenceQueue.remove chiamati dalGarbage Collector sono fra le causeprincipali del degrado.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Scalabilita

3 + 6! stati 248 sStruct.unify 1947041Var.unify 2584249Var.free 18025053 + 2 ∗ 6! stati 489 sStruct.unify 3876572Var.unify 5181011Var.free 36017503 + 3 ∗ 6! stati 1898 sObject.wait 2ReferenceQueue.remove 4Struct.unify 5813154Var.unify 7768221Var.free 5398379

Sono stati analizzati i tempi diesecuzione per risoluzioni di obiettivisempre piu complessi.

La funzione (tempo diesecuzione)/(numero di stati) e lineareper obiettivi semplici.

Ma per obiettivi piu complessi leprestazioni degradano.

Anche il numero delle chiamate aimetodi e proporzionale al numerodegli stati.

I metodi Object.wait eReferenceQueue.remove chiamati dalGarbage Collector sono fra le causeprincipali del degrado.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Scalabilita

3 + 6! stati 248 sStruct.unify 1947041Var.unify 2584249Var.free 18025053 + 2 ∗ 6! stati 489 sStruct.unify 3876572Var.unify 5181011Var.free 36017503 + 3 ∗ 6! stati 1898 sObject.wait 2ReferenceQueue.remove 4Struct.unify 5813154Var.unify 7768221Var.free 5398379

Sono stati analizzati i tempi diesecuzione per risoluzioni di obiettivisempre piu complessi.

La funzione (tempo diesecuzione)/(numero di stati) e lineareper obiettivi semplici.

Ma per obiettivi piu complessi leprestazioni degradano.

Anche il numero delle chiamate aimetodi e proporzionale al numerodegli stati.

I metodi Object.wait eReferenceQueue.remove chiamati dalGarbage Collector sono fra le causeprincipali del degrado.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Scalabilita

3 + 6! stati 248 sStruct.unify 1947041Var.unify 2584249Var.free 18025053 + 2 ∗ 6! stati 489 sStruct.unify 3876572Var.unify 5181011Var.free 36017503 + 3 ∗ 6! stati 1898 sObject.wait 2ReferenceQueue.remove 4Struct.unify 5813154Var.unify 7768221Var.free 5398379

Sono stati analizzati i tempi diesecuzione per risoluzioni di obiettivisempre piu complessi.

La funzione (tempo diesecuzione)/(numero di stati) e lineareper obiettivi semplici.

Ma per obiettivi piu complessi leprestazioni degradano.

Anche il numero delle chiamate aimetodi e proporzionale al numerodegli stati.

I metodi Object.wait eReferenceQueue.remove chiamati dalGarbage Collector sono fra le causeprincipali del degrado.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

0

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

0

1

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

2Int.unify

0

1

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

2Int.unify

3Term.match

0

1

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

2Int.unify

3Term.match

0

1 4

Var.r

enam

e

Struct.<init>Struct.toString

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

2Int.unify

3Term.match

5Term.match

0

1 4

Var.r

enam

e

Struct.<init>Struct.toString

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dei tempi di esecuzione

Analisi dei metodi

N. Nome metodo Esec %- Object.wait 12,150 Var.occurCheck 3,701 Struct.getTerm 3,062 Var.unify 3,053 AbstractStringBuilder.append 2,824 Var.free 2,615 Struct.unify 2,25

2Int.unify

3Term.match

5Term.match

0

1 4

Var.r

enam

e

Struct.<init>Struct.toString

Il metodo Object.wait e mediamente quello che occupa la maggior parte del tempodi esecuzione delle teorie.

Le classi Var e Struct sono complessivamente le piu utilizzate.

L’implementazione della struttura Term, Var e Struct deve essere rivista.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Analisi degli oggetti allocati

Nome oggetto M. allocata %Object[] 27,40char[] 14,71ArrayList 7,90AbstractList$Itr 6,95Struct 5,37String 4,15Term[] 3,82Var 3,50StringBuffer 1,82

Nove classi istanziano il 75% dellamemoria totale allocata.

Le classi ArrayList e AbstractList$Itrvengono utilizzate in maggior mododallo stesso metodo.

ArrayList istanzia uno o piu oggettiObject[] nel suo tempo di vita.

Lo stesso vale per String eStringBuffer che istanziano oggettichar[].

Le classi Struct e Var sonospecializzazioni di Term e la stessaStruct contiene array di Term.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Analisi degli oggetti allocati

Nome oggetto M. allocata %Object[] 27,40char[] 14,71ArrayList 7,90AbstractList$Itr 6,95Struct 5,37String 4,15Term[] 3,82Var 3,50StringBuffer 1,82

Nove classi istanziano il 75% dellamemoria totale allocata.

Le classi ArrayList e AbstractList$Itrvengono utilizzate in maggior mododallo stesso metodo.

ArrayList istanzia uno o piu oggettiObject[] nel suo tempo di vita.

Lo stesso vale per String eStringBuffer che istanziano oggettichar[].

Le classi Struct e Var sonospecializzazioni di Term e la stessaStruct contiene array di Term.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Analisi degli oggetti allocati

Nome oggetto M. allocata %Object[] 27,40char[] 14,71ArrayList 7,90AbstractList$Itr 6,95Struct 5,37String 4,15Term[] 3,82Var 3,50StringBuffer 1,82

Nove classi istanziano il 75% dellamemoria totale allocata.

Le classi ArrayList e AbstractList$Itrvengono utilizzate in maggior mododallo stesso metodo.

ArrayList istanzia uno o piu oggettiObject[] nel suo tempo di vita.

Lo stesso vale per String eStringBuffer che istanziano oggettichar[].

Le classi Struct e Var sonospecializzazioni di Term e la stessaStruct contiene array di Term.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Analisi degli oggetti allocati

Nome oggetto M. allocata %Object[] 27,40char[] 14,71ArrayList 7,90AbstractList$Itr 6,95Struct 5,37String 4,15Term[] 3,82Var 3,50StringBuffer 1,82

Nove classi istanziano il 75% dellamemoria totale allocata.

Le classi ArrayList e AbstractList$Itrvengono utilizzate in maggior mododallo stesso metodo.

ArrayList istanzia uno o piu oggettiObject[] nel suo tempo di vita.

Lo stesso vale per String eStringBuffer che istanziano oggettichar[].

Le classi Struct e Var sonospecializzazioni di Term e la stessaStruct contiene array di Term.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Analisi degli oggetti allocati

Nome oggetto M. allocata %Object[] 27,40char[] 14,71ArrayList 7,90AbstractList$Itr 6,95Struct 5,37String 4,15Term[] 3,82Var 3,50StringBuffer 1,82

Nove classi istanziano il 75% dellamemoria totale allocata.

Le classi ArrayList e AbstractList$Itrvengono utilizzate in maggior mododallo stesso metodo.

ArrayList istanzia uno o piu oggettiObject[] nel suo tempo di vita.

Lo stesso vale per String eStringBuffer che istanziano oggettichar[].

Le classi Struct e Var sonospecializzazioni di Term e la stessaStruct contiene array di Term.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Cause delle allocazioni

N. Nome oggetto0 Object[]1 char[]2 ArrayList3 AbstractList$Itr4 Struct5 String6 Term[]7 Var8 StringBuffer 0

Term

.mat

ch

ClauseStore.deunify

2ClauseStore.deunify

Var.f

ree

3

Term

.mat

ch

ClauseStore.deunify

I metodi ClauseStore.deunify e Term.match causano la maggior partedell’allocazione della memoria.

Escludendo poche eccezioni Var.rename e l’unico metodo ad allocare oggettiString, StringBuilder e char[] che vale il 20% della memoria totale allocata.

Come per i tempi di esecuzione la struttura Term - Struct - Var dovrebbe essereresa piu leggera.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Cause delle allocazioni

N. Nome oggetto0 Object[]1 char[]2 ArrayList3 AbstractList$Itr4 Struct5 String6 Term[]7 Var8 StringBuffer 5

Var.rename8

Var.rename

1Var.rename

I metodi ClauseStore.deunify e Term.match causano la maggior partedell’allocazione della memoria.

Escludendo poche eccezioni Var.rename e l’unico metodo ad allocare oggettiString, StringBuilder e char[] che vale il 20% della memoria totale allocata.

Come per i tempi di esecuzione la struttura Term - Struct - Var dovrebbe essereresa piu leggera.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Analisi dell’utilizzo della memoria

Cause delle allocazioni

N. Nome oggetto0 Object[]1 char[]2 ArrayList3 AbstractList$Itr4 Struct5 String6 Term[]7 Var8 StringBuffer

4

6 7

I metodi ClauseStore.deunify e Term.match causano la maggior partedell’allocazione della memoria.

Escludendo poche eccezioni Var.rename e l’unico metodo ad allocare oggettiString, StringBuilder e char[] che vale il 20% della memoria totale allocata.

Come per i tempi di esecuzione la struttura Term - Struct - Var dovrebbe essereresa piu leggera.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Confronto con la versione 1.3

Confronto con la versione 1.3

Sono stati messi a confronto i tempi di escuzione e l’utilizzo dellamemoria delle versioni 2.1 e 1.3 di tuProlog.

Nelle teorie sottoposte a test la nuova versione e risultata piu lentadella vecchia, con un aumento dei tempi medio del 20%.

Anche per quanto concerne la memoria allocata si e visto un aumentomedio del 20% nella versione 2.1 rispetto alla 1.3.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Confronto con la versione 1.3

Confronto con la versione 1.3

Sono stati messi a confronto i tempi di escuzione e l’utilizzo dellamemoria delle versioni 2.1 e 1.3 di tuProlog.

Nelle teorie sottoposte a test la nuova versione e risultata piu lentadella vecchia, con un aumento dei tempi medio del 20%.

Anche per quanto concerne la memoria allocata si e visto un aumentomedio del 20% nella versione 2.1 rispetto alla 1.3.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Profiling di tuProlog Confronto con la versione 1.3

Confronto con la versione 1.3

Sono stati messi a confronto i tempi di escuzione e l’utilizzo dellamemoria delle versioni 2.1 e 1.3 di tuProlog.

Nelle teorie sottoposte a test la nuova versione e risultata piu lentadella vecchia, con un aumento dei tempi medio del 20%.

Anche per quanto concerne la memoria allocata si e visto un aumentomedio del 20% nella versione 2.1 rispetto alla 1.3.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java

Conclusioni

Conclusioni

Il garbage collector causa un degrado consistente dei tempi diesecuzione.

Un miglioramento dell’efficienza in termini di allocazione di memoriacausa indirettamente un miglioramento dei tempi di esecuzione.

Term e le sue specializzazioni Struct e Var vanno reimplementate.

In particolare il metodo Term.match causa sia un aumentoconsiderevole dei tempi di esecuzione sia della memoria utilizzata.

Suggerimenti

Aumentare la capacita iniziale della struttura dati ArrayList in mododa limitare il numero di Object[] che essa alloca.

Sostituire la classe String in Var.rename con StringBuilder, piu velocee meno avida di memoria nelle operazioni di append.

Michele Damian Analisi di prestazione dell’interprete tuProlog su piattaforma Java