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
lib/libc/tests/nss
- Convert the testcases to ATF
- Do some style(9) cleanups:
-- Sort headers
-- Apply indentation fixes
-- Remove superfluous parentheses
- Explicitly print out debug printfs for use with `kyua {debug,report}`; for
items that were overly noisy, they've been put behind #ifdef DEBUG
conditionals
- Fix some format strings
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
The normal LIBADD is ssp_nonshared. This also had a DPADD on LIBSSP which
does not actually exist, it is blank.
Sponsored by: EMC / Isilon Storage Division
This is so that 'make depend' is not a required build step in these
files.
DPSRCS is overall unneeded. DPSRCS already contains SRCS, so anything
which can safely be in SRCS should be. DPSRCS is mostly just a way to
generate files that should not be linked into the final PROG/LIB. For
headers and grammars it is safe for them to be in SRCS since they will
be excluded during linking and installation.
The only remaining uses of DPSRCS are for generating .c or .o files that
must be built before 'make depend' can run 'mkdep' on the SRCS c files
list. A semi-proper example is in tests/sys/kern/acct/Makefile where a
checked-in .c file has an #include on a generated .c file. The
generated .c file should not be linked into the final PROG though since
it is #include'd. The more proper way here is just to build/link it in
though without DPSRCS. Another example is in sys/modules/linux/Makefile
where a shell script runs to parse a DPSRCS .o file that should not be
linked into the module. Beyond those, the need for DPSRCS is largely
unneeded, redundant, and forces 'make depend' to be ran. Generally,
these Makefiles should avoid the need for DPSRCS and define proper
dependencies for their files as well.
An example of an improper usage and why this matters is in usr.bin/netstat.
nl_defs.h was only in DPSRCS and so was not generated during 'make all',
but only during 'make depend'. The files including it lacked proper
depenencies on it, which forced running 'make depend' to workaround that
bug. The 'make depend' target should mostly be used for incremental build
help, not to produce a working build. This specific example was broken in
the meta build until r287905 since it does not run 'make depend'.
The gnu/lib/libreadline/readline case is fine since bsd.lib.mk has 'OBJS:
SRCS:M*.h' when there is no .depend file.
Sponsored by: EMC / Isilon Storage Division
MFC after: 1 week
(HOST_SHELL is used in NetBSD)
This fixes permission denied issues when gen_ether_subr is not executable
MFC after: 3 days
Reported by: José Pérez <fbl@aoek.com>
Suggested by: bdrewery, sjg
- Split up the testcases into C locale and ja_JP.eucJP testcases.
- Avoid a segfault in the event that setlocale fails, similar to r290843
- Replace `sizeof(x) / sizeof(*x)` pattern with `nitems(x)`
MFC after: 1 week
X-MFC with: r290532
Sponsored by: EMC / Isilon Storage Division
Provide more meaningful diagnostic messages if LC_CTYPE can't be set properly
instead of segfaulting, because setlocale returns NULL and strcmp(NULL, b) will
always segfault
Split up the testcases so one failing (in this case en_US.ISO8859-15) won't
cause the rest of the testcases to be skipped
Remove some unused variables
MFC after: 1 week
X-MFC with: r290532
Sponsored by: EMC / Isilon Storage Division
as lib/libc/tests/gen
The code in test-fnmatch that was used for generating:
- bin/sh/tests/builtins/case2.0
- bin/sh/tests/builtins/case3.0
has been left undisturbed. The target `make sh-tests` has been moved over
from tools/regression/lib/libc/gen/Makefile to
lib/libc/tests/gen/Makefile and made into a PHONY target
case2.0 and case3.0 test input generation isn't being done automatically.
This needs additional discussion.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
- Remove a leftover printf from when this was a TAP based testcase
- Catch mmap failures properly
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
as lib/libc/tests/net
Also, fix eui64_aton_test:test_str(..). The test was comparing the result
of eui64_aton to a pointer of the expected result.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
provided on amd64, but not i386. Add libm to DPADD/LDADD to unbreak the i386
tinderbox
Pointyhat to: ngie
MFC after: 1 week
X-MFC with: r290538
Sponsored by: EMC / Isilon Storage Division
as lib/libc/tests/stdlib
- Make the code a bit more style(9) compliant
- Convert a sizeof(x)/sizeof(x[0]) to nitems
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
Only enable h_raw on x86 targets for today so that a buildworld runs to
completion for clang enabled targets that are not x86. This should be
removed when validation of the sanitizer has occured for all targets
supported by FreeBSD and clang.
as lib/libc/rpc
This testcase requires rpcbind be up in running; otherwise the testcases
will time out and be skipped
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
netbsd-tests.test.mk (r289151)
- Eliminate explicit OBJTOP/SRCTOP setting
- Convert all ad hoc NetBSD test integration over to netbsd-tests.test.mk
- Remove unnecessary TESTSDIR setting
- Use SRCTOP where possible for clarity
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Divison
Connect it to the build.
The code assumed that SCHED_* constants form a contiguous set of
numbers, remove the assumption by using schedulers[] array in
get_different_scheduler(). This is no-op on FreeBSD, but improves
code portability.
The selection of different priority used the min/max priority range of
the current scheduler class, instead of the priority to be changed to.
The bug caused the test failure.
Remove duplication of POSIX_SPAWN_SETSIGDEF flag and now unused
duplications of MIN/MAX definitions.
Reviewed by: jilles, pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3533
Each issue has a PR open to track. This workaround allows us to run the
tests to investigate the failures and avoid any new regressions.
PR: 202304, 202305, 202307
Reviewed by: ngie
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3378
