From 7d74fad152388b297628a3c0096025d9ac9a61f0 Mon Sep 17 00:00:00 2001 From: Lorenz Stechauner Date: Wed, 3 Sep 2025 23:41:52 +0200 Subject: [PATCH] thesis: Add text for manipulation performance test --- thesis/src/05.evaluation.tex | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/thesis/src/05.evaluation.tex b/thesis/src/05.evaluation.tex index 3132c97..e0e5182 100644 --- a/thesis/src/05.evaluation.tex +++ b/thesis/src/05.evaluation.tex @@ -152,9 +152,19 @@ Measuring performance for function call manipulation makes no sense without know 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 unlikely to yield meaningful results and was not carried out. -\todo{Update text} +Despite this, a simple performance test has been conducted. +The setup was the same as in Subsection~\ref{subsec:performance-intercepting}. +But this time \texttt{intercept.so} was configured to connect to a Unix domain socket. +At first, a simple C program was used to respond to the messages on the socket, only using \texttt{getline} and \texttt{fprintf}. +For the first test run the program always responded with the \texttt{"ok"} command (``Manipulate (simple ok)''), for the second with the \texttt{"return 0"} command (``Manipulate (simple return)''). +After that, the default Python implementation developed in this work, which parses the incoming messages automatically, was tested. +Again, at first always responding with the \texttt{"ok"} command (``Manipulate (Python ok)''), and then with the \texttt{"return 0"} command (``Manipulate (Python return)''). +Figure~\ref{fig:manipulate-performance} illustrates the results and some previous measurements for context. + +Results of the simple C program show, that the communication over the socket alone has only minimal overhead compared with ``Logging to stderr''. +Due to the parsing of messages the Python program has slightly worse performance degradation. +(The ``return'' test is slightly faster compared to the ``ok'' test, because the \texttt{pipe} function normally responds with \texttt{return 0; errno 0; fildes=[7,8]}, but when using \texttt{"return 0"} it responds with \texttt{return 0; errno 0}, which is less data to parse.) \begin{figure} \centering @@ -218,5 +228,5 @@ Therefore, an explicit performance test on manipulation was deemed unlikely to y \end{axis} \end{tikzpicture} \caption{Execution times of a simple program using \texttt{intercept.so} with different manipulation modes.} - \label{fig:manupulate-performance} + \label{fig:manipulate-performance} \end{figure}