summaryrefslogtreecommitdiff
path: root/Tests
diff options
context:
space:
mode:
authorkleines Filmröllchen <filmroellchen@serenityos.org>2022-03-07 22:24:15 +0100
committerAndreas Kling <kling@serenityos.org>2022-03-31 12:06:13 +0200
commite73e5794462341f6ffa0bf46f03e4c4c5a884604 (patch)
tree2c691765099f853d97ed8344c9158409145c0c2f /Tests
parentbcb893789862380cd9199915c205d8986c3dc407 (diff)
downloadserenity-e73e5794462341f6ffa0bf46f03e4c4c5a884604.zip
Tests: Introduce a HashTable benchmark for "table thrashing"
Thrashing is what I call the situations where a table is mostly filled with deleted markers, causing an increase in size (at least temporarily) when a simple re-hash would be enough to get rid of those. This happens when a hash table (especially with many elements) has a lot of deletes and re-inserts done to it, which is what this benchmark does.
Diffstat (limited to 'Tests')
-rw-r--r--Tests/AK/TestHashTable.cpp18
1 files changed, 18 insertions, 0 deletions
diff --git a/Tests/AK/TestHashTable.cpp b/Tests/AK/TestHashTable.cpp
index a521763e23..2e3ddc5582 100644
--- a/Tests/AK/TestHashTable.cpp
+++ b/Tests/AK/TestHashTable.cpp
@@ -234,3 +234,21 @@ TEST_CASE(capacity_leak)
}
EXPECT(table.capacity() < 100u);
}
+
+// Inserting and removing a bunch of elements will "thrash" the table, leading to a lot of "deleted" markers.
+BENCHMARK_CASE(benchmark_thrashing)
+{
+ HashTable<int> table;
+ // Ensure that there needs to be some copying when rehashing.
+ table.set(3);
+ table.set(7);
+ table.set(11);
+ table.set(13);
+ for (int i = 0; i < 10'000; ++i) {
+ table.set(-i);
+ }
+ for (int i = 0; i < 10'000'000; ++i) {
+ table.set(i);
+ table.remove(i);
+ }
+}