thesis: Add text for manipulation performance test
This commit is contained in:
@@ -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}
|
||||||
|
|||||||
Reference in New Issue
Block a user