FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F14.4.0 2023-11-27T04:20:09Z 2023-11-27T04:20:09Z Warner Losh imp@FreeBSD.org 2023-11-01T22:43:37Z urn:sha1:4025b5b527c870cf095ac9531764f4e4d3feaec2 These sys/cdefs.h are not needed. Purge them. They are mostly left-over from the $FreeBSD$ removal. A few in libc are still required for macros that cdefs.h defines. Keep those. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D42385 (cherry picked from commit 559a218c9b257775fb249b67945fe4a05b7a6b9f) 2023-08-16T17:54:42Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:42Z urn:sha1:1d386b48a555f61cb7325543adbbb5c3f3407a66 Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 2016-10-13T18:25:40Z Ed Schouten ed@FreeBSD.org 2016-10-13T18:25:40Z urn:sha1:4ef9bd22ed091dd6513f89cdca2dfd03b6e3ffd2 Back in 2015 when I reimplemented these functions to use an AVL tree, I was annoyed by the weakness of the typing of these functions. Both tree nodes and keys are represented by 'void *', meaning that things like the documentation for these functions are an absolute train wreck. To make things worse, users of these functions need to cast the return value of tfind()/tsearch() from 'void *' to 'type_of_key **' in order to access the key. Technically speaking such casts violate aliasing rules. I've observed actual breakages as a result of this by enabling features like LTO. I've filed a bug report at the Austin Group. Looking at the way the bug got resolved, they made a pretty good step in the right direction. A new type 'posix_tnode' has been added to correspond to tree nodes. It is still defined as 'void' for source-level compatibility, but in the very far future it could be replaced by a proper structure type containing a key pointer. MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8205 2016-01-14T07:27:42Z Ed Schouten ed@FreeBSD.org 2016-01-14T07:27:42Z urn:sha1:31969237964b5e529aae30002608713c428965cb tdelete() is supposed to return the address of the parent node that has been deleted. We already keep track of this node in the loop between lines 94-107. The GO_LEFT()/GO_RIGHT() macros are used later on as well, so we must make sure not to change it to something else. 2015-12-22T18:12:11Z Ed Schouten ed@FreeBSD.org 2015-12-22T18:12:11Z urn:sha1:459d04a5eecbe8ea330ef9c6cbba6392b16d317e 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-02-06T14:22:00Z Pedro F. Giffuni pfg@FreeBSD.org 2015-02-06T14:22:00Z urn:sha1:02aa7d7b57f1037b0449603b4a20df6939328999 The NetBSD revisions correspond to changes we have already done like __P() removal and ANSI-fication of definitions. 2015-02-05T23:02:43Z Pedro F. Giffuni pfg@FreeBSD.org 2015-02-05T23:02:43Z urn:sha1:b20592de1b2a780f7610dba094fbb7331f31a264 CID: 272528 Obtained from: NetBSD (CVS rev. 1.4) MFC after: 2 weeks 2003-01-05T02:43:18Z Tim J. Robbins tjr@FreeBSD.org 2003-01-05T02:43:18Z urn:sha1:051900864f8b60454e360eb2ef36e245b4d3e647 2002-09-06T11:24:06Z Tim J. Robbins tjr@FreeBSD.org 2002-09-06T11:24:06Z urn:sha1:58d38e25205c6ee5ef0796ffa2cd8e2ca6c6e7f3 2002-08-14T21:16:41Z Robert Drehmel robert@FreeBSD.org 2002-08-14T21:16:41Z urn:sha1:840b798c83238d9477451fc3f3af180ca6249e59 prototype of the tdelete(3) function. - Remove duplicated space. - Use an ANSI-C function definition for tdelete(3). - Update the manual page.