Refactor body of periodic and delete performance test cases of splinter_test to utilize shared functions carved out in #334

[gapisback]

Issue #334 introduces refactoring of body splinter_test function into sub-functions. Apply those to chunks of test_splinter_periodic() and test_splinter_delete(), so that we can reduce code duplication.

[gapisback]

HI, @ajhconway - Qs about refactoring test_splinter_periodic() - not urgent; take your time.

I was working on refactoring test_splinter_periodic() to use previously refactored / modularized functions, and see that this function seems to reduce to the following sequence of perf-execution workloads:

1. splinter_perf_inserts()
2. 10 repeat_round iterations to call (a newly refactored) splinter_do_perf_inserts(); i.e. just run the n-insert threads again. But, nothing seems to be obviously changing across each iteration of the insert workload in this loop (from /main):

1440 platform_status
1441 test_splinter_periodic(trunk_config    *cfg,
[...]
1581    for (uint64 repeat_round = 0; repeat_round < 10; repeat_round++) {
1582       platform_default_log("Beginning repeat round %lu\n", repeat_round);
1583       platform_error_log("Beginning repeat round %lu\n", repeat_round);

3. splinter_perf_lookups()
4. splinter_perf_range_lookups()

Other than step (2), the work load executed is identical to what's happening with --perf option; i.e. test_splinter_perf().

Unless I am making some obvious mistakes, missing to see some "subtle conditions" in the periodic perf function, there does not seem to be anything new being added with --periodic option.

Do you recall what's diff or special about this --periodic variation of --perf option? Am I missing something with this refactoring?

[ajhconway]

The idea behind test_splinter_periodic was to do a bunch of overwrites in order to test the performance. I don't recall exactly why. Perhaps @rtjohnso remembers.