From 620e40c0cb95003674c9916be8afc8598e682c07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20Sch=C3=A4rtl?= <andreas@schaertl.me>
Date: Thu, 24 Sep 2020 13:56:55 +0200
Subject: [PATCH] report: applications: write about pre-computed scores

---
 doc/report/applications.tex | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/doc/report/applications.tex b/doc/report/applications.tex
index 3795bb9..58c6119 100644
--- a/doc/report/applications.tex
+++ b/doc/report/applications.tex
@@ -157,6 +157,20 @@ do anyways. Either way, this is not so much an issue for the
 organizational storage engine and more one that a tetrapodal search
 aggregator has to account for.
 
+Another problem is that computing these scores can be quite time
+intensive. Even if calculating a score for one given object is fast,
+doing so for the whole data set might quickly turn into a problem.  In
+particular, if we wish to show the $n$~object with best scores, we do
+need to compute scores for all relevant triplets for that score. In
+\emph{ulo-storage}, all scores we experimented with were easy enough
+and the data sets small enough that that this did not become a
+concrete problem. But in a larger tetrapodal search system, caching or
+lazily or ahead of time computed results will probably we a
+necessity. Which component takes care of keeping this cache is not
+clear right now, but we advocate for keeping caches of previously
+computed scores separate from the core \emph{ulo-storage} Endpoint
+such that the Endpoint can be easily updated.
+
 \subsubsection{Categorizing Algorithms and Algorithmic Problems}
 
 The second query~$\mathcal{Q}_2$ we decided to focus on wants to
-- 
GitLab