Mention that perfs would be affected by prod version
This commit is contained in:
parent
b128ddd571
commit
9e09921c2a
1 changed files with 14 additions and 0 deletions
|
@ -1014,6 +1014,15 @@ Table~\ref{table:bench_time}.
|
|||
\caption{Time benchmarking on hackbench}\label{table:bench_time}
|
||||
\end{table}
|
||||
|
||||
The performance of \ehelfs{} is probably overestimated, since \ehelfs{} do not
|
||||
handle all registers from the original DWARF file, and thus the
|
||||
\prog{libunwind} version must perform more computation. However, this overhead,
|
||||
although impossible to measure without first implementing supports for every
|
||||
register, would probably not be that big, since most of the time is spent
|
||||
finding the relevant row. Support for every DWARF instruction, however, would
|
||||
not slow down at all the implementation, since every instruction would simply
|
||||
be compiled to x86\_64 without affecting the already supported code.
|
||||
|
||||
It is also worth noting that on the machine described in
|
||||
Section~\ref{ssec:bench_hw}, the compilation of the \ehelfs{} at a level of
|
||||
\lstc{-O2} needed to run \prog{hackbench}, that is, \prog{hackbench},
|
||||
|
@ -1036,6 +1045,11 @@ way smaller \lstc{.eh_frame}, thus, the outlined data is reused only a few
|
|||
times, compared to \eg{} \prog{libc}, in which the outlined data is reused a
|
||||
lot.
|
||||
|
||||
Just as with time performance, the measured compactness would be impacted by
|
||||
supporting every register, but probably not that much either, since most
|
||||
columns are concerned with the four supported registers (see
|
||||
Section~\ref{ssec:instr_cov}).
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\begin{tabular}{r r r r r r}
|
||||
|
|
Loading…
Reference in a new issue