\section*{Optimization}
For this master thesis, my main goal will be to optimize the performance of ipyparallel by coming up with new solutions to solve the mentioned paint points. One of the main advantages to using ipyparallel is that you can have a distributed set of engines running in parallel to solve some problem. This already works well for small to medium sized computations, but to achieve high performance on highly parallel problems running on >100s of engines, some more work can be done. The idea is that by using caching and making some of the non-parallel parts of the program also run in parallel we can significantly increase the performance.

\begin{figure}[!h]
\begin{center}
        \includegraphics[width=15cm]{client-scheduler2.png}
    \caption{Proposal for a new architecture for client-scheduler-engine communication.}\label{architecture proposal 1}
\end{center}
\end{figure}
\paragraph*{Client-Scheduler-Engine Communication}  ~\\
With the goal of increasing the performance of the client-scheduler-engine communication, an interesting strategy could be to change the architecture so that instead of having one scheduler, we could make a spanning tree of schedulers. The difference will be that instead of having just one scheduler doing all of the communication, we will have schedulers that starts new schedulers so that in the end we will have different levels of schedulers, were each schedulers only communicates with the components in the level above and below. This would make it possible to scale the number of schedulers in regards to the number of engines so that the new schedulers has to do much less work than the current implemented scheduler. One of the obvious challenges for architecture is that the latency will increase between the client and the engine, but this increase is likely to be trivial in comparison with performance gains from having a more parallel system. I will also have to figure out a good function to determine the right amount of schedulers to create in order to gain optimal performance. With the proposed architecture the number of messages the scheduler has to send will decrease from O(n) to something closer to O(log(n)).
Note to self publisher/subscriber pattern?

\paragraph*{Object serialization}  ~\\
Implement some kind of caching.

\vspace*{\fill}
\pagebreak