Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <20596747.22731272920699868.JavaMail.jira@thor>
Date: Mon, 3 May 2010 17:04:59 -0400 (EDT)
From: "Nicolas Labrot (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-1043) Faster UUID comparisons
In-Reply-To: <26344418.9191272858715984.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863512#action_12863512 ] 

Nicolas Labrot commented on CASSANDRA-1043:
-------------------------------------------

I will just add a comment on the test. Like the optimisation uses the internal structure of Jug UUID it should be valusable to add a test on it.

for example with asserts on value of UUID.INDEX_CLOCK_HI, UUID.INDEX_CLOCK_MID and INDEX_CLOCK_MID.INDEX_CLOCK_LO

> Faster UUID comparisons
> -----------------------
>
>                 Key: CASSANDRA-1043
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1043
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: James Golick
>            Assignee: James Golick
>            Priority: Minor
>             Fix For: 0.7
>
>         Attachments: faster-uuid-compare-v3.diff, faster_uuid_compare.diff, patch-v2-with-tests.diff
>
>
> As I explained on the mailing list, doing slice queries on CFs that are sorted by TimeUUIDType gets slower as the value of count increases. According to my profiles, this is largely due to the fact that ConcurrentSkipListMap calls the comparator very frequently, which is extremely inefficient. In order to compare two UUIDs, it has to materialize them both in to java.util.UUID objects which is quite slow. The more UUIDs to compare, the slower it is.
> Attached is a patch that compares UUIDs by extracting the timestamp directly from the byte[] representation. According to my tests, it's close to a 50% performance improvement.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.