From 9e09921c2a6d95cc5b09d8074d28eb653cdae81a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Th=C3=A9ophile=20Bastian?= Date: Wed, 8 Aug 2018 14:19:29 +0200 Subject: [PATCH] Mention that perfs would be affected by prod version --- report/report.tex | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/report/report.tex b/report/report.tex index 035c264..ee71bd6 100644 --- a/report/report.tex +++ b/report/report.tex @@ -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}