1
0

thesis: Add text for manipulation performance test

This commit is contained in:
2025-09-03 23:41:52 +02:00
parent bb5bd436d0
commit ea00123e40

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. 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. This also applies to function call manipulation.
The performance degradation heavily depends on the response speed of the used socket. 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. Despite this, a simple performance test has been conducted.
\todo{Update text}
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} \begin{figure}
\centering \centering
@@ -218,5 +228,5 @@ Therefore, an explicit performance test on manipulation was deemed unlikely to y
\end{axis} \end{axis}
\end{tikzpicture} \end{tikzpicture}
\caption{Execution times of a simple program using \texttt{intercept.so} with different manipulation modes.} \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} \end{figure}