\documentclass[../thesis.tex]{subfiles}
\begin{document}

\chapter{Conclusion}

% Summary of the goals
% What was created?

The goal of this thesis was to implement a novel energy profiler for the Perun project and together with a way to visualize the results it creates. The profiler is capable of sampling at high frequencies the energy consumption of a system and put that consumed energy into the context of system calls. The profiler operates with low overhead, requires minimum number of dependencies and is publicly available under the GPLv3 license. Moreover we proposed a reporting tool capable of using the profiler's output data to create both text reports and visualizations of the profiled data providing a comprehensive and easy-to-use way to interpret the profiler's results.

% Results of the experiments

We evaluated the profiler on a series of experiments where the GNOME Shell software was profiled in different runtime environments. The experimental evaluation showed that the profiler \begin{enumerate*}[\alph*)]\item is capable of locating "hot spots" in the runtime of applications, and, \item is capable of picking up differences in the profiling runtime conditions \end{enumerate*}.

% Near future - Perun integration; Long-term future work

\paragraph{Future work.} The next step is to fully integrate the energy profiler in the Perun project as a new collector. Because the implementation of the profiler was designed with this goal in mind, this step should be straightforward. Adding support to the profiler to trace multiple processes could help in reducing the effect of noise on the results of the profiler by using the additional system call traces in the scoring algorithm. The informational value of the profiler could also be increased significantly by adding support for scoring functions in \Glspl{callgraph}. The performance of the reporting tool could be improved by leveraging a plotting module making use of multiple threads or even GPU \Glspl{api}.

% Dashboard

% As mentioned in previous section (\ref{sysrapl-report-limitations}) generating a report in the form of a dashboard could improve the comprhensibility of \verb|sysrapl-report|.

% Use of different plotting library to enhance speed and provide interaction

% The use of a different plotting library could apart from boost in processing speed provide additional features like interaction and dynamic scaling of the plotted data. This could make for example the heatmap (sysrapl-report-system-calls-energy-time-heatmap) a much more versatile form of visualization.

% Better statistical processing (alternative to IQR,...)

% \verb|sysrapl-report| uses \Gls{iqr} to filter out outliers. Alternative approaches to filtering out outliers and in general more robust analysis techniques could further enhance the quality of the profile data.

% Use of Dask (or something else) instead of Pandas to further enhance speed

% \emph{Pandas}~\cite{PandasPythonData} proved to be a reliable and efficient module for data manipulation. Alternative projects like \emph{Polars}~\cite{Polars} or \emph{Dask}~\cite{Dask} claim to provide better performance while providing API similar or even equal to that of \emph{Pandas}. Use of these modules instead of \emph{Pandas} could further improve the tool's average runtime.

\end{document}
