fedir/ICFS-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated info

Browse Source
This commit is contained in:
fedir 2025-04-15 19:36:51 +02:00
parent 7518b25a6d
commit 1a09bd99af
Signed by: fedir
GPG Key ID: C959EE85F0C9362C
1 changed files with 2 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
evaluation.tex
View File

@ -42,17 +42,9 @@ As for regular terminal programs, I see these possible solutions:
\section{Performance}
Performance of ICFS is terrible. Unfortunately, I was unable to make \verb|perf| work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck.
A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems.
But a lot can also be improved. For example,
\begin{itemize}
\item sqlite queries can be pre-``compiled''
\item (I think) more paralellism can be achieved.
\end{itemize}
Performance of ICFS is terrible. \sout{Unfortunately, I was unable to make perf work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck. A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems.}
I managed to get the \verb|perf| to work: it showed that almost all time was consumed by libfuse, not my program. My code used something like 0.0001\% of runtime on a pretty heavy test. I am not quite sure what to do, since libfuse is already optimised to smithereens. I guess I will just write how it is and not touch the performance ever again.
\section{Limitations}
\label{eval:limit}