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

thesis: Complete 5.2

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-08-14 23:43:26 +02:00
parent a0cb199a34
commit 5b47630fab
1 changed files with 21 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -69,18 +69,31 @@ For some functions the modification of function arguments has been implemented.
\section{Performance}\label{sec:performance} \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. 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} \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} \begin{figure}
\centering \centering
\begin{tikzpicture} \begin{tikzpicture}
\begin{axis}[ \begin{axis}[
xmin=0, xmax=5000, xmin=100, xmax=5000,
ymin=0, ymax=150, ymin=0, ymax=150,
scaled y ticks=false, scaled y ticks=false,
ymajorgrids=true, ymajorgrids=true,
@@ -133,4 +146,8 @@ Lorem Ipsum.
\subsection{Performance when Manipulating}\label{subsec:performance-manipulating} \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.