Page Comparison

...

• Ran clusterperf basic to measure overhead of the new structure/code
  • no perceivable difference in basic read and write performance.
• Summary of micro benchmarks to measure the performance of the 'getKey()' function

• configuration	Old format	New format
  Single key, key in contiguous memory	6 - 7 ns	8.42 ns	6 - 7 ns
  key in a Buffer (single key)	25 ns	---
  key in a Buffer (50 secondary keys). Measure the first call to getKey()	---	25 ns
  key in a Buffer (50 secondary keys). Measure the second call to getKey() on the same object	---	11.75 ns

• The difference in performance between the first call to getKey() and a subsequent call to getKey() for the same object is due to the following optimization.
  • There are many inefficient methods to return a key from the object. What is important here is that we can expect this function to be very frequently, both by the client side code and the server side code
  • This also motivated a change in the object format storing cumulative key length values rather than lengths of each individual key.
  • The inefficiencies mainly arise if the object doesn't exist in contiguous memory and instead lies in a buffer that may not be contiguous.
  • Since, the object can be arbitrarily large, we don't want to copy all the keys and the value into contiguous memory upfront.
  • So, the first call to getKey() or any similar function that directly deals with keys like getKeyLength() etc will populate a structure that can store the number of keys in the object and all the cumulative key length values in contiguous memory. Notice that the size of this is roughly (2 * numKeys) bytes only.
  • For ever subsequent call to getKey(), the cumulative key length values already exist in memory. So the only thing that remains is to copy the key into contiguous memory based on its offset within the object