1 files changed, 42 insertions, 1 deletions

diff --git a/chapters/design-space.tex b/chapters/design-space.tex
index f788a7a..64b658f 100644
--- a/chapters/design-space.tex
+++ b/chapters/design-space.tex
@@ -725,7 +725,7 @@ and VPTree.
 \centering
 \subfloat[ISAM Tree Range Count]{\includegraphics[width=.5\textwidth]{img/design-space/isam-parm-sweep.pdf} \label{fig:design-isam-tradeoff}} 
 \subfloat[VPTree $k$-NN]{\includegraphics[width=.5\textwidth]{img/design-space/knn-parm-sweep.pdf} \label{fig:design-knn-tradeoff}} \\
-\caption{Insertion Throughput vs. Query Latency}
+\caption{Insertion Throughput vs. Query Latency for varying scale factors}
 \label{fig:design-tradeoff}
 \end{figure}
 
@@ -771,6 +771,47 @@ performance across the board. Generally it seems to be a strictly worse
 alternative to leveling in all but its best-case query cost, and we will
 omit it from our tests moving forward.
 
+\subsection{Buffer Size}
+
+\begin{figure}
+\centering
+\subfloat[ISAM Tree Range Count]{\includegraphics[width=.5\textwidth]{img/design-space/isam-bs-sweep.pdf} \label{fig:buffer-isam-tradeoff}} 
+\subfloat[VPTree $k$-NN]{\includegraphics[width=.5\textwidth]{img/design-space/knn-bs-sweep.pdf} \label{fig:buffer-knn-tradeoff}} \\
+\caption{Insertion Throughput vs. Query Latency for varying buffer sizes}
+\label{fig:buffer-size}
+\end{figure}
+
+In the previous section, we considered the effect of various scale
+factors on the trade-off between insertion and query performance. Our
+framework also supports varying buffer sizes, and so we will examine this
+next. Figure~\ref{fig:buffer-size} shows the same insertion throughput
+vs. query latency curves for fixed layout policy and scale factor
+configurations at varying buffer sizes.
+
+Unlike with the scale factor, there is a significant difference in the
+behavior of the two tested structures under buffer size variation. For
+the ISAM tree, shown in Figure~\ref{fig:buffer-isam-tradeoff}, we see that
+all layout policies follow a similar pattern. Increasing the buffer size
+increases insertion throughput for little to no additional query cost up
+to a certain point, after which query performance degrades substantially.
+This isn't terribly surprising: growing the buffer size will increase
+the number of records on each level, and therefore decrease the number
+of shards, while at the same time reducing the number of reconstructions
+that must be performed. However, the query must be answered against the
+buffer too, and once the buffer gets sufficiently large, this increased
+cost will exceed any query latency benefit from decreased shard count.
+We see this pattern fairly clearly on all tested configurations, however
+BSM sees the least benefit from an increased buffer size in terms of
+insertion performance.
+
+VPTree is another story, shown in Figure~\ref{fig:buffer-knn-tradeoff}.
+This plot is far more chaotic; in fact there aren't any particularly
+strong patterns to draw from it. This is likely due to the fact that the
+time scales associated with the VPTree in terms of both reconstruction
+and query latency are significantly larger, and so the relatively small
+constant associated with adjusting the buffer size doesn't have as strong
+an influence on performance as it does for the ISAM tree.
+
 \subsection{Query Size Effects}
 
 One potentially interesting aspect of decomposition-based dynamization