lorenz.stechauner/BSc-Thesis
1
0
Fork 0
Code Activity

thesis: Add text for manipulation performance test

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-09-03 23:41:52 +02:00
parent bb5bd436d0
commit 7d74fad152
1 changed files with 13 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
thesis/src/05.evaluation.tex
View File

@@ -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}