diff options
author | kleines Filmröllchen <filmroellchen@serenityos.org> | 2022-03-07 22:24:15 +0100 |
---|---|---|
committer | Andreas Kling <kling@serenityos.org> | 2022-03-31 12:06:13 +0200 |
commit | e73e5794462341f6ffa0bf46f03e4c4c5a884604 (patch) | |
tree | 2c691765099f853d97ed8344c9158409145c0c2f /Tests | |
parent | bcb893789862380cd9199915c205d8986c3dc407 (diff) | |
download | serenity-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.cpp | 18 |
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); + } +} |