From 5c459cb16751d9fa6fb15cfc6ffb42e1ad133e12 Mon Sep 17 00:00:00 2001 From: Sears Russell Date: Sat, 26 Mar 2005 03:31:55 +0000 Subject: [PATCH] ... --- doc/paper2/LLADD.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/paper2/LLADD.tex b/doc/paper2/LLADD.tex index c81cadc..0a3bbe5 100644 --- a/doc/paper2/LLADD.tex +++ b/doc/paper2/LLADD.tex @@ -1850,10 +1850,10 @@ memory to achieve good performance. to object serialization. First, since \yad supports custom log entries, it is trivial to have it store deltas to the log instead of writing the entire object during an update. -Such an optimization would be difficult to achieve with Berkeley DB -since the only diff-based mechanism it supports requires changes to -span contiguous regions of a record, which is not necessarily the case for arbitrary -object updates. +%Such an optimization would be difficult to achieve with Berkeley DB +%since the only diff-based mechanism it supports requires changes to +%span contiguous regions of a record, which is not necessarily the case for arbitrary +%object updates. %% \footnote{It is unclear if %% this optimization would outweigh the overheads associated with an SQL @@ -2022,10 +2022,10 @@ only one integer field from a ~1KB object is modified, the fully optimized \yad correspond to a twofold speedup over the unoptimized \yad. -In all cases, the update rate for mysql\footnote{We ran mysql using +In all cases, the update rate for MySQL\footnote{We ran MySQL using InnoDB for the table engine, as it is the fastest engine that provides similar durability to \yad. For this test, we also linked directly -with the mysqld daemon library, bypassing the RPC layer. In +with the libmysqld daemon library, bypassing the RPC layer. In experiments that used the RPC layer, test completion times were orders of magnitude slower.} is slower than Berkeley DB, which is slower than any of the \yad variants. This performance @@ -2063,7 +2063,7 @@ compact, object-specific diffs that \oasys produces are correctly applied. The custom log format, when combined with direct access to the page file and buffer pool, drastically reduces disk and memory usage for write intensive loads. A simple extension to our recovery algorithm makes it -easy to implement other similar optimizations in the future. +easy to implement similar optimizations in the future. %This section uses: % @@ -2089,7 +2089,7 @@ requests by reordering invocations of wrapper functions. \subsection {Data Representation} For simplicity, we represent graph nodes as -fixed-length records. The Array List from our linear hash table +fixed-length records. The ArrayList from our linear hash table implementation (Section~\ref{sub:Linear-Hash-Table}) provides access to an array of such records with performance that is competitive with native recordid accesses, so we use an ArrayList to store the records. We @@ -2111,7 +2111,7 @@ application, but we note that the memory utilization of the simple depth-first search algorithm is certainly no better than the algorithm presented in the next section. -Also, for simplicity, we do not apply any of the optimizations in +For simplicity, we do not apply any of the optimizations in Section~\ref{OASYS}. This allows our performance comparison to measure only the optimization presented here. @@ -2142,7 +2142,7 @@ logging format and wrapper functions to implement a purely logical log. For our graph traversal algorithm we use a {\em log demultiplexer}, shown in Figure~\ref{fig:multiplexor} to route entries from a single log into many sub-logs according to page number. This is easy to do -with the Array List representation that we chose for our graph, since +with the ArrayList representation that we chose for our graph, since it provides a function that maps from array index to a $(page, slot, size)$ triple.