>Once you have something like Oracle or an LDAP server serving out
>multi-megabyte data files, the equivalent btree is going to get awefully
>deep awefully quickly, and there's no simple way to expand the width of
>the tree dynamically to minimise that cost.
I have to agree with you ;). You are right and I was just worried about
that. Ok, I think I wasted time implemented rb-trees. At least it's been
fun.
>In other words, I can throw memory at hashing to make it faster, but
>trees have a fixed cost which necessarily grows with their size.
Agreed. Probably in normal usage rb-trees may scale better also because
most of files are not huge in size. But the performance drop that will
increase with the file size is bad and I agree that it's better to have a
clean design that can scale with minor changes under all scenarios.
I think tomorrow I'll drop RB-trees from here too.
If somebody think that it can make sense to have a rb-tree patch updated
with my latest changes, ask me and I'll produce it while removing
rbtrees from here (sigh!)...
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/