diff --git a/thesis/src/05.evaluation.tex b/thesis/src/05.evaluation.tex
index 180df25..3a1b9ba 100644
--- a/thesis/src/05.evaluation.tex
+++ b/thesis/src/05.evaluation.tex
@@ -69,18 +69,31 @@ For some functions the modification of function arguments has been implemented.
 \section{Performance}\label{sec:performance}
 
 Although high performance was not a primary goal of this work, the resulting performance degradation by intercepting and manipulation should not be too excessive.
-The following two subsections test the performance degradation of \texttt{intercept.so} compared to running a program without any intercepting or hooking.
+The following two subsections test and discuss the performance degradation of \texttt{intercept.so} compared to running a program without any intercepting or hooking.
 
 
 \subsection{Performance when Intercepting}\label{subsec:performance-intercepting}
 
-Lorem Ipsum.
+To test the performance of \texttt{intercept.so} the following measurement environment was set up.
+On an x86-64 machine with an AMD Ryzen 7 7700X 8-Core processor a simple program was called with an increasing number of iterations it had to perform.
+The program simply called the \texttt{pipe} function and then closed the created pipes in a for loop.
+At first execution time of the program was measured without using \texttt{intercept.so} (``Baseline'').
+Then \texttt{intercept.so} was preloaded but without any action to perform when intercepting (``Intercepting'').
+After that, logging to \texttt{stderr} was enabled (``Logging to stderr'').
+Finally, the logs were written to a file (``Logging to file'').
+For each of the four variants, the program was called with an iteration count beginning at 100 and increasing in steps of 100 up to 5000.
+Each measurement was taken 30 times with one second between program executions to rule out statistical outliers.
+Figure~\ref{fig:performance} illustrates the results.
+
+It is clearly visible, that the initialization step of \texttt{intercept.so} always takes around 10 ms.
+In comparison to that, the performance degradation of the intercepting procedure alone is negligible, only around +13 \% compared to the baseline execution (see ``Intercept -- 10 ms'' and ``Baseline'').
+Most delay comes from logging the recorded function calls.
 
 \begin{figure}
   \centering
   \begin{tikzpicture}
     \begin{axis}[
-        xmin=0, xmax=5000,
+        xmin=100, xmax=5000,
         ymin=0, ymax=150,
         scaled y ticks=false,
         ymajorgrids=true,
@@ -133,4 +146,8 @@ Lorem Ipsum.
 
 \subsection{Performance when Manipulating}\label{subsec:performance-manipulating}
 
-Lorem Ipsum.
+Measuring performance for function call manipulation makes no sense without knowing the exact socket server to be used.
+As seen in Subsection~\ref{subsec:performance-intercepting}, most delay comes not from intercepting itself, but from the further processing.
+This also applies to function call manipulation.
+The performance degradation heavily depends on the response speed of the used socket.
+Therefore, an explicit performance test on manipulation was deemed not yielding meaningful result and not carried out.