Daily CheckIn

chapters/thesis/appendix02_timing.sh

@@ -96,10 +96,8 @@ hostname="http://localhost:8080/WedekindJSF-1.0.0"
 # the Array of the Urls
 url_arr=(
     "$hostname/index.xhtml"
-    "$hostname/view/document/list.xhtml"
-    #"$hostname/view/document/listsearch.xhtml"
-    #"$hostname/view/correspondent/list.xhtml"
-    #"$hostname/view/person/list.xhtml"
+    #"$hostname/view/document/list.xhtml"
+    "$hostname/view/document/listsearch.xhtml"
 )
 
 #print_process

chapters/thesis/chapter05.tex

@@ -585,8 +585,17 @@ Nach dem Anpassungen haben sich dann die Werte aus \ref{tbl:measure-materialized
     \label{tbl:measure-materialized-view-ext}
 \end{table}
 
+Da bei der Materialized View das laden der Daten und das wandeln in die Java"=Objekte getrennt programmiert wurde,
+können hier eigene Zeitmessungen für die zwei Schritte eingebaut werden. Hierfür wird die Zeit vor dem
+\textit{map}"=Aufruf und der \textit{map}"=Aufruf gemessen. Für den ersten Aufruf, wurde ein \textit{SearchDocument}
+Objekt erzeugt und immer diese Objekt zurückgegeben. Damit wurde erst mal überprüft, wie lange das ermitteln der Daten
+und das durcharbeiten der Ergebnisse bestimmt. Hierbei lagen die Zeiten bei ca. 1 ms für das reine Datenladen und 3 ms
+für den Aufruf der \textit{map}"=Funktion. Sobald mal innerhalb der \textit{map}"=Funktion pro Eintrag ein Objekt
+erzeugt, noch ohne eine Konvertierung der ermittelten Daten in das Objekt, steigt die Laufzeit schon auf 54 ms.
+Wenn man nun noch die Konvertierung der Daten wieder einbaut, steigt die Laufzeit nochmal auf nun 82 ms.
+Dies zeigt, alleine das erzeugen der Objekt kostet die meiste Zeit.
+
 %\mytodos{hier noch darauf eingehen, dass die Hauptarbeit nicht beim editieren sondern bei der Anzeige ist}
-\mytodos{Das Render des Json in der View Betrachten, scheint der aktuelle Kostenpunkt zu sein}
 \mytodos{Hier könnte man auch den Query-Cache nochmal verwenden, da die anfragen nun fix wären}
 \mytodos{Grundlagen zur Materialized-View noch hinterlegen}