I wrote:
> - Try templating out the differences between local and shared memory.
Here is a brief progress report before Christmas vacation.
I thought the best way to approach this was to go "inside out", that is, start with the modest goal of reducing duplicated code for v16.
0001-0005 are copies from v13.
0006 whacks around the rt_node_insert_inner function to reduce the "surface area" as far as symbols and casts. This includes replacing the goto with an extra "unlikely" branch.
0007 removes the STRICT pragma for one of our benchmark functions that crept in somewhere -- it should use the default and not just return NULL instantly.
0008 further whacks around the node-growing code in rt_node_insert_inner to remove casts. When growing the size class within the same kind, we have no need for a "new32" (etc) variable. Also, to keep from getting confused about what an assert build verifies at the end, add a "newnode" variable and assign it to "node" as soon as possible.
0009 uses the bitmap logic from 0004 for node256 also. There is no performance reason for this, because there is no iteration needed, but it's good for simplicity and consistency.
0010 and 0011 template a common implementation for both leaf and inner nodes for searching and inserting.
0012: While at it, I couldn't resist using this technique to separate out delete from search, which makes sense and might give a small performance boost (at least on less capable hardware). I haven't got to the iteration functions, but they should be straightforward.
There is more that could be done here, but I didn't want to get too ahead of myself. For example, it's possible that struct members "children" and "values" are names that don't need to be distinguished. Making them the same would reduce code like
+#ifdef RT_NODE_LEVEL_LEAF
+ n32->values[insertpos] = value;
+#else
+ n32->children[insertpos] = child;
+#endif
...but there could be downsides and I don't want to distract from the goal of dealing with shared memory.
The tests pass, but it's not impossible that there is a new bug somewhere.
--
John Naylor
EDB:
http://www.enterprisedb.com
