Closed gapisback closed 6 months ago
During stabilization of shared memory support (PR #569 ), debug-build debug/bin/driver_test btree_test --use-shmem --seed 135 shows the following profile in perf top:
debug/bin/driver_test btree_test --use-shmem --seed 135
perf top
Overhead Shared Object Symbol 9.97% libsplinterdb.so [.] sizeof_ondisk_tuple_data 7.94% libsplinterdb.so [.] clockcache_config_page_size 7.35% libsplinterdb.so [.] btree_get_leaf_entry 6.31% libsplinterdb.so [.] btree_verify_node 5.33% driver_test [.] slice_lex_cmp 4.90% libsplinterdb.so [.] cache_config_page_size
There seems to be simple refactoring of calls to clockcache_page_size() in tight loops, which should help reduce this run-time overheads.
clockcache_page_size()
The test has been running for several minutes, and it will be helpful to reduce this run-time:
test.sh: Sat Dec 9 20:42:48 PST 2023 BTree test, key size=8 bytes, using shared memory: 742 s [ 0h 12m 22s ] test.sh: Sat Dec 9 20:52:22 PST 2023 BTree test, with default key size, using shared memory: 574 s [ 0h 9m 34s ] test.sh: Sat Dec 9 20:58:29 PST 2023 BTree test, key size=100 bytes, using shared memory: 367 s [ 0h 6m 7s ] test.sh: Sat Dec 9 21:01:47 PST 2023 BTree Perf test, using shared memory: 198 s [ 0h 3m 18s ]
During stabilization of shared memory support (PR #569 ), debug-build
debug/bin/driver_test btree_test --use-shmem --seed 135
shows the following profile inperf top
:There seems to be simple refactoring of calls to
clockcache_page_size()
in tight loops, which should help reduce this run-time overheads.The test has been running for several minutes, and it will be helpful to reduce this run-time: