- 16 Jun, 2019 1 commit
-
-
pwrdwnsys authored
-
- 14 Jun, 2019 1 commit
-
-
pwrdwnsys authored
-
- 27 Feb, 2019 1 commit
-
-
Harris Hancock authored
InsertionOrderIndex manages memory, but it didn't have an explicit move constructor or move assignment operator, causing segmentation faults and double frees.
-
- 22 Aug, 2018 1 commit
-
-
Oleg Kolosov authored
Have not found a universal way to detect C11 and after some deliberation __BIONIC__ seems to be a better choice for these cases.
-
- 21 Aug, 2018 1 commit
-
-
Oleg Kolosov authored
Reorder ifdef checks in BTreeImpl::growTree to make posix_memalign the default case and hide aligned_alloc behind feature test macro. This covers more systems and actually fixes the compatibility with Android.
-
- 19 Aug, 2018 1 commit
-
-
Kenton Varda authored
-
- 05 Aug, 2018 10 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Integer division is really, really slow. The integer hash table benchmark spends most of its time in modulus operations! This change shaves 32% off the integer hash table benchmark runtime, and 8% off the string hash table benchmark runtime.
-
Kenton Varda authored
-
Kenton Varda authored
This is true even if the pointer-to-member is never actually used, but only has its type matched, which was what kj::size() was trying to do. Oh well, define some damned constants instead.
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
Hash-based (unordered) and tree-based (ordered) indexing are provided. kj::Table offers advantages over STL: - A Table can have multiple indexes (allowing lookup by multiple keys). Different indexes can use different algorithms (e.g. hash vs. tree) and have different uniqueness constraints. - The properties on which a Table is indexed need not be explicit fields -- they can be computed from the table's row type. - Tables use less memory and make fewer allocations than STL, because rows are stored in a contiguous array. - The hash indexing implementation uses linear probing rather than chaining, which again means far fewer allocations and more cache-friendliness. - The tree indexing implementation uses B-trees optimized for cache line size, whereas STL uses cache-unfriendly and allocation-heavy red-black binary trees. (However, STL trees are overall more cache-friendly; see below.) - Most of the b-tree implementation is not templated. This reduces code bloat, at the cost of some performance due to virtual calls. On an ad hoc benchmark on large tables, the hash index implementation appears to outperform libc++'s `std::unordered_set` by ~60%. However, libc++'s `std::set` still outperforms the B-tree index by ~70%. It looks like the B-tree implementation suffers in part from the fact that keys are not stored inline in the tree nodes, forcing extra memory indirections. This is a price we pay for lower memory usage overall, and the ability to have multiple indexes on one table. The b-tree implementation also suffers somewhat from not being 100% templates, compared to STL, but I think this is a reasonable trade-off. The most performance-critical use cases will use hash indexes anyway.
-