freebsd-dev/include/search.h

81 lines
1.6 KiB
C
Raw Normal View History

/*-
* Written by J.T. Conklin <jtc@NetBSD.org>
* Public domain.
*
* $NetBSD: search.h,v 1.16 2005/02/03 04:39:32 perry Exp $
* $FreeBSD$
*/
#ifndef _SEARCH_H_
#define _SEARCH_H_
#include <sys/cdefs.h>
#include <sys/_types.h>
#ifndef _SIZE_T_DECLARED
typedef __size_t size_t;
#define _SIZE_T_DECLARED
#endif
typedef struct entry {
char *key;
void *data;
} ENTRY;
typedef enum {
FIND, ENTER
} ACTION;
typedef enum {
preorder,
postorder,
endorder,
leaf
} VISIT;
#ifdef _SEARCH_PRIVATE
typedef struct node {
Let tsearch()/tdelete() use an AVL tree. The existing implementations of POSIX tsearch() and tdelete() don't attempt to perform any balancing at all. Testing reveals that inserting 100k nodes into a tree sequentially takes approximately one minute on my system. Though most other BSDs also don't use any balanced tree internally, C libraries like glibc and musl do provide better implementations. glibc uses a red-black tree and musl uses an AVL tree. Red-black trees have the advantage over AVL trees that they only require O(1) rotations after insertion and deletion, but have the disadvantage that the tree has a maximum depth of 2*log2(n) instead of 1.44*log2(n). My take is that it's better to focus on having a lower maximum depth, for the reason that in the case of tsearch() the invocation of the comparator likely dominates the running time. This change replaces the tsearch() and tdelete() functions by versions that create an AVL tree. Compared to musl's implementation, this version is different in two different ways: - We don't keep track of heights; just balances. This is sufficient. This has the advantage that it reduces the number of nodes that are being accessed. Storing heights requires us to also access all of the siblings along the path. - Don't use any recursion at all. We know that the tree cannot 2^64 elements in size, so the height of the tree can never be larger than 96. Use a 128-bit bitmask to keep track of the path that is computed. This allows us to iterate over the same path twice, meaning we can apply rotations from top to bottom. Inserting 100k nodes into a tree now only takes 0.015 seconds. Insertion seems to be twice as fast as glibc, whereas deletion has about the same performance. Unlike glibc, it uses a fixed amount of memory. I also experimented with both recursive and iterative bottom-up implementations of the same algorithm. This iterative top-down version performs similar to the recursive bottom-up version in terms of speed and code size. For some reason, the iterative bottom-up algorithm was actually 30% faster for deletion, but has a quadratic memory complexity to keep track of all the parent pointers. Reviewed by: jilles Obtained from: https://github.com/NuxiNL/cloudlibc Differential Revision: https://reviews.freebsd.org/D4412
2015-12-22 18:12:11 +00:00
void *key;
struct node *llink, *rlink;
Let tsearch()/tdelete() use an AVL tree. The existing implementations of POSIX tsearch() and tdelete() don't attempt to perform any balancing at all. Testing reveals that inserting 100k nodes into a tree sequentially takes approximately one minute on my system. Though most other BSDs also don't use any balanced tree internally, C libraries like glibc and musl do provide better implementations. glibc uses a red-black tree and musl uses an AVL tree. Red-black trees have the advantage over AVL trees that they only require O(1) rotations after insertion and deletion, but have the disadvantage that the tree has a maximum depth of 2*log2(n) instead of 1.44*log2(n). My take is that it's better to focus on having a lower maximum depth, for the reason that in the case of tsearch() the invocation of the comparator likely dominates the running time. This change replaces the tsearch() and tdelete() functions by versions that create an AVL tree. Compared to musl's implementation, this version is different in two different ways: - We don't keep track of heights; just balances. This is sufficient. This has the advantage that it reduces the number of nodes that are being accessed. Storing heights requires us to also access all of the siblings along the path. - Don't use any recursion at all. We know that the tree cannot 2^64 elements in size, so the height of the tree can never be larger than 96. Use a 128-bit bitmask to keep track of the path that is computed. This allows us to iterate over the same path twice, meaning we can apply rotations from top to bottom. Inserting 100k nodes into a tree now only takes 0.015 seconds. Insertion seems to be twice as fast as glibc, whereas deletion has about the same performance. Unlike glibc, it uses a fixed amount of memory. I also experimented with both recursive and iterative bottom-up implementations of the same algorithm. This iterative top-down version performs similar to the recursive bottom-up version in terms of speed and code size. For some reason, the iterative bottom-up algorithm was actually 30% faster for deletion, but has a quadratic memory complexity to keep track of all the parent pointers. Reviewed by: jilles Obtained from: https://github.com/NuxiNL/cloudlibc Differential Revision: https://reviews.freebsd.org/D4412
2015-12-22 18:12:11 +00:00
signed char balance;
} node_t;
struct que_elem {
struct que_elem *next;
struct que_elem *prev;
};
#endif
#if __BSD_VISIBLE
struct hsearch_data {
Replace implementation of hsearch() by one that scales. Traditionally the hcreate() function creates a hash table that uses chaining, using a fixed user-provided size. The problem with this approach is that this often either wastes memory (table too big) or yields bad performance (table too small). For applications it may not always be easy to estimate the right hash table size. A fixed number only increases performance compared to a linked list by a constant factor. This problem can be solved easily by dynamically resizing the hash table. If the size of the hash table is at least doubled, this has no negative on the running time complexity. If a dynamically sized hash table is used, we can also switch to using open addressing instead of chaining, which has the advantage of just using a single allocation for the entire table, instead of allocating many small objects. Finally, a problem with the existing implementation is that its deterministic algorithm for hashing makes it possible to come up with fixed patterns to trigger an excessive number of collisions. We can easily solve this by using FNV-1a as a hashing algorithm in combination with a randomly generated offset basis. Measurements have shown that this implementation is about 20-25% faster than the existing implementation (even if the existing implementation is given an excessive number of buckets). Though it allocates more memory through malloc() than the old implementation (between 4-8 pointers per used entry instead of 3), process memory use is similar to the old implementation as if the estimated size was underestimated by a factor 10. This is due to the fact that malloc() needs to perform less bookkeeping. Reviewed by: jilles, pfg Obtained from: https://github.com/NuxiNL/cloudlibc Differential Revision: https://reviews.freebsd.org/D4644
2015-12-27 07:50:11 +00:00
struct __hsearch *__hsearch;
};
#endif
__BEGIN_DECLS
int hcreate(size_t);
void hdestroy(void);
ENTRY *hsearch(ENTRY, ACTION);
void insque(void *, void *);
void *lfind(const void *, const void *, size_t *, size_t,
int (*)(const void *, const void *));
void *lsearch(const void *, void *, size_t *, size_t,
int (*)(const void *, const void *));
void remque(void *);
void *tdelete(const void * __restrict, void ** __restrict,
int (*)(const void *, const void *));
void *tfind(const void *, void * const *,
int (*)(const void *, const void *));
void *tsearch(const void *, void **, int (*)(const void *, const void *));
void twalk(const void *, void (*)(const void *, VISIT, int));
#if __BSD_VISIBLE
int hcreate_r(size_t, struct hsearch_data *);
void hdestroy_r(struct hsearch_data *);
int hsearch_r(ENTRY, ACTION, ENTRY **, struct hsearch_data *);
#endif
__END_DECLS
#endif /* !_SEARCH_H_ */