Thu, Jul 9
I take it that this test does not do any lookups? I am personally not overly concerned by a pessimization in a write-heavy benchmark, since a binary search tree is probably not the best choice for that scenario to begin with.
Adding a test result to reflect the downside of this change. If you replace the sorted inserts and removals with randomly generated ones (random() % maxsize), then the red-black tree takes this time:
Wed, Jul 8
Apply reviewer suggestions.
For a test case that inserts and removes items in sorted order, so that the tree stays as unbalanced as possible, this modification improves performance from
and no color-balancing at all would be terrible.
Tighten up RB_REMOVE_COLOR a bit.
Tue, Jun 30
Optimize the color-changing code in RB_INSERT_COLOR and RB_REMOVE_COLOR by allowing both colors to be set to red, or not-red, at once, in some cases.
Sun, Jun 28
Move the handling of the deleting-a-leaf special coloring case from RB_REMOVE to RB_REMOVE_COLOR, to avoid entangling rebalancing with augmentation.
Simplify RB_REMOVE. Let RB_REMOVE_COLOR do more of the color changing.
Sat, Jun 27
Add checking for null parent in RB_REMOVE.
Restoring the missing tree.h changes.
Assuming that the failure to compile is because of the RB_AUGMENT call not within a loop, change to put it within a trivial loop. I've been testing with non-null augmentation so that this problem was not apparent.
Oh, the irony. :)
Please give me a few days to read up on WAVL trees, I haven't encountered them before. (I know I usually take a few days anyway, sorry about that.)
Fri, Jun 26
Thu, Jun 25
Wed, Jun 24
Apply reviewer suggestions.
In RB_REMOVE_COLOR, treat the null parent-of-root as red, to avoid having the next iteration with a null parent pointer.
Fixup RB_SET_PARENT after a hasty cut and paste.
Tue, Jun 23
Clean up RB_SET_PARENT.
Same change as before, from the right directory this time.
Include the root-of-tree case.
Sat, Jun 20
If I understand correctly, with the original code, the intermediate state of the tree prior to the second rotation after removing 7 is:B6:17 B5:11 B4:6 R2:2
Fri, Jun 19
Thu, Jun 18
See also vm_fault_quick_hold_pages in vm_fault.c.
Drop redundant assignments.
A little test program. Enter a positive number to insert into the tree and a negative number to remove its inverse from the tree.
Tue, Jun 16
Sun, Jun 14
Take RB_SET_PARENT out of RB_SWAP_CHILD; it doesn't belong when the incoming child is NULL.
Add a cast to (struct linux_root *).
Sat, Jun 13
Fri, Jun 12
Address some omissions in this patch before I abandon it.
Don't modify 'new' in rb_replace_node.
Jun 10 2020
Jun 9 2020
I'm also happy to just change the subr_stats.c code. Having RB_TREE and ARB_TREE bound tightly like this makes another RB_TREE change I'm considering impossible.
Jun 7 2020
Don't depend on anyone else's bool type.
Jun 6 2020
Remove redundant assignments.
Jun 5 2020
This change makes a newly inserted node black, not red, and lets RB_INSERT_COLOR make it red if it needs to be. So rb_link_node no longer needs to be concerned with redness - the default black color is correct. Nowhere else in sys/ is code that depend on rb_color, rb_is_red or rb_is_black, so delete them and the tree.h macros that had been defined to enable them.
Fix color in rb_link_node.
Jun 4 2020
Fix order of arguments in the RB_SET_COLOR invocation in rbtree.h.
Jun 3 2020
Replace "typeof" with "__typeof".
Restore COLOR in a way that linux compatibilty headers demand.
Correct an error in determining the redness of the successor of an interior node being deleted.
Jun 2 2020
Jun 1 2020
I apologize for failing to test for successful compilation.
Change the null test back to a redness test, in a way to encourage the compiler to skip the test when possible.
Discard the second part of the change and see if the first part is broken.
An assignment to black can be dropped in one case, but not the other, so fix that.
May 30 2020
May 27 2020
May 21 2020
May 18 2020
Use a local variable for RB_PARENT(old, field).