cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Zhuang (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9989) Optimise BTree.Buider
Date Fri, 24 Aug 2018 00:32:00 GMT


Jay Zhuang commented on CASSANDRA-9989:

[~benedict], thank you very much for the review.

I updated the branch based on your comments: [{{branch: 9989}}|].
{quote}1. How did you arrive at your childrenNum calculation, and are we certain it is correct?
This is pretty critical for correctness, and hard to test fully, so it would be nice to have
some comments justifying it.
 4. It would be nice if we removed MAX_DEPTH, and just truncated TREE_SIZE to the correct
maximum in our static block
Fixed. Now it auto calculates the max height of the tree that we could build.
{quote}2. Why decrement left instead of just counting up the number of values written?
It's used to update [{{indexOffsets\[i\]}}|].
{quote}3. Why is TREE_SIZE indexed from 1, not 0?
Just to make the initial calculation easier: [{{TREE_SIZE\[i-1\]}}|].
With the new patch, it's also used here: to get [{{grandchildSize}}|].
{quote}I'm also torn on the splitting of the last two nodes - this is consistent with the
current NodeBuilder logic, but it does complicate the code a little versus evenly splitting
the remaining size amongst all the children.
I was thinking to make the tree a little bit more balanced by splitting it equally to the
last 2 nodes. But yes, it also makes sense to make it the same as before. I updated the code
and added an unittest to make sure the BTree is [exactly the same|]
as before (with {{[NodeBuilder()|]}}).

> Optimise BTree.Buider
> ---------------------
>                 Key: CASSANDRA-9989
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Benedict
>            Assignee: Jay Zhuang
>            Priority: Minor
>             Fix For: 4.x
>         Attachments: 9989-trunk.txt
> BTree.Builder could reduce its copying, and exploit toArray more efficiently, with some
work. It's not very important right now because we don't make as much use of its bulk-add
methods as we otherwise might, however over time this work will become more useful.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message