[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14804759#comment-14804759 ] Tommaso Barbugli commented on CASSANDRA-8730: - any chance to see this patched in 2.0 branch? > Optimize UUIDType comparisons > - > > Key: CASSANDRA-8730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 > Project: Cassandra > Issue Type: Improvement >Reporter: J.B. Langston >Assignee: Benedict > Labels: performance > Fix For: 2.2.0 beta 1 > > > Compaction is slow on tables using compound keys containing UUIDs due to > being CPU bound by key comparison. [~benedict] said he sees some easy > optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14804767#comment-14804767 ] Brandon Williams commented on CASSANDRA-8730: - No. > Optimize UUIDType comparisons > - > > Key: CASSANDRA-8730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 > Project: Cassandra > Issue Type: Improvement >Reporter: J.B. Langston >Assignee: Benedict > Labels: performance > Fix For: 2.2.0 beta 1 > > > Compaction is slow on tables using compound keys containing UUIDs due to > being CPU bound by key comparison. [~benedict] said he sees some easy > optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14804770#comment-14804770 ] Aleksey Yeschenko commented on CASSANDRA-8730: -- bq. any chance to see this patched in 2.0 branch? 2.0 line has officially been declared EOL, and the next release (2.0.17) is going to be the final one. You could apply the patch manually though and build from source. > Optimize UUIDType comparisons > - > > Key: CASSANDRA-8730 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 > Project: Cassandra > Issue Type: Improvement >Reporter: J.B. Langston >Assignee: Benedict > Labels: performance > Fix For: 2.2.0 beta 1 > > > Compaction is slow on tables using compound keys containing UUIDs due to > being CPU bound by key comparison. [~benedict] said he sees some easy > optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353302#comment-14353302 ] Ariel Weisberg commented on CASSANDRA-8730: --- I am +1 Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 3.0 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14348607#comment-14348607 ] Benedict commented on CASSANDRA-8730: - bq. UUIDType is supposed to correctly compare TimeUUIDTypes Regrettably, no it isn't. It actually has a different comparison logic for the LSB of the TimeUUID. bq. What is UUIDTypeTest.permute used to check for? I've commented this method now, but it is to exhaustively check each of the permutations of any given comparison point (i.e. each byte for all but the byte containing the UUID type, and the top 4 bits only for that byte). I've also updated the tests to randomise the input to the permutations, although logically this should have no impact. bq. Maybe resurrect the old versions to check that they are prior version consistent in the unit tests. Maybe modify the test to use a seeded RNG with a known seed and print it out so if there is a failure we can reproduce. Sure, added to branch. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 3.0 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347767#comment-14347767 ] Ariel Weisberg commented on CASSANDRA-8730: --- I've gone over this a couple of times. It looks okay and the tests are persuasive that they check that the comparisons are self-consistent. Maybe resurrect the old versions to check that they are prior version consistent in the unit tests. Maybe modify the test to use a seeded RNG with a known seed and print it out so if there is a failure we can reproduce. UUIDType is supposed to correctly compare TimeUUIDTypes and there is some cut and paste so it maybe it should use TimeUUID in parallel and see if both approaches return the same answer when LHS and RHS are both Time UUIDs? What is UUIDTypeTest.permute used to check for? Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 3.0 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345416#comment-14345416 ] Benedict commented on CASSANDRA-8730: - I've pushed a small change with a very simple trick to permit both faster and simpler signed byte comparison of the LSB in TimeUUIDTyoe Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 3.0 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14320590#comment-14320590 ] Aleksey Yeschenko commented on CASSANDRA-8730: -- Feasible - maybe, if you want a custom patch. But this will go into 3.0 officially, most likely. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14320585#comment-14320585 ] J.B. Langston commented on CASSANDRA-8730: -- Looks like these changes are fairly isolated to two classes... would this be feasible to backport to 2.0? Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[
https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14311947#comment-14311947
]
Sylvain Lebresne commented on CASSANDRA-8730:
-
bq. It looks to me like TimeUUID had the behaviour downgraded to CQL2 only,
whereas UUID has not.
The code inconsistency is likely just a historical accident, but it kind of
doesn't matter much since {{fromString}} will never be called by CQL3 (on a
date-string) as CQL3 only accepts UUID literals for UUID (not string literals,
contrarily to CQL2). So as long as we preserve the behavior for CQL2 until 3.0,
we can make the {{fromString}} implementations consistent by either accepting
or rejecting dates in both case (I'd personally go with rejecting dates as it's
dangerous in the first place, but I don't care enough to argument more than
that if someone disagree).
bq. makes TimeUUIDType extend UUIDType
While I don't mind the extension per-se, we have to be careful on the
comparison because unfortunately, TimeUUIDType does *not* compare as UUIDType
does. That is, after having compared the timestamps, UUIDType perform an
unsigned comparison of the lsb, while TimeUUIDType uses
[ByteBuffer.compareTo|http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compareTo(java.nio.ByteBuffer)]
which does a byte-signed comparison. Before someone asks, there is no good
excuse for doing so, it's a pretty old mistake, but it's not something we can
afford to break now.
As an aside, I personally think this should be targeted at 3.0 (it's not a bug
fix). Also, as even subtly changing the comparison would have desastrous
consequence, it would be nice to add a few tests that checks that old and new
versions compare the same way (we can't be exhaustive, but we can get a fair
coverage of all code path easily enough).
Optimize UUIDType comparisons
-
Key: CASSANDRA-8730
URL: https://issues.apache.org/jira/browse/CASSANDRA-8730
Project: Cassandra
Issue Type: Improvement
Reporter: J.B. Langston
Assignee: Benedict
Fix For: 2.1.4
Compaction is slow on tables using compound keys containing UUIDs due to
being CPU bound by key comparison. [~benedict] said he sees some easy
optimizations that could be made for UUID comparison.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14311986#comment-14311986 ] Benedict commented on CASSANDRA-8730: - bq. while TimeUUIDType uses ByteBuffer.compareTo which does a byte-signed comparison Good catch. I would still prefer that these extend each other, because the cleanup is I think useful and makes it more obvious they are interdependent. But this does eliminate some of the benefit, and perhaps this should be done in a separate patch. bq. Also, as even subtly changing the comparison would have desastrous consequence, it would be nice to add a few tests that checks that old and new versions compare the same way Sure. The current code already does some randomized testing, that I was planning to up the ante on and run a burn test in, but there's no reason not to introduce some specific tests for a mutation of each conditional comparison in the old code. bq. As an aside, I personally think this should be targeted at 3.0 (it's not a bug fix). I have no particular position on this. It's a pretty contained change though, so I would be comfortable introducing it in 2.1, but have no strong preference versus 3.0. Whilst I was a bit careless in the extension, I was careful in the UUIDType rewrite to ensure the semantics of the comparison are the same. The only semantic change I've introduced here is to assert the size of the data is _exactly_ 16 bytes, or zero, which I'm comfortable omitting, or delaying, or introducing. However anybody else feels strongly. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312474#comment-14312474 ] J.B. Langston commented on CASSANDRA-8730: -- 12.88MB/sec from the latest code. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312119#comment-14312119 ] Benedict commented on CASSANDRA-8730: - OK, I've pushed an updated version that strips out all of the class cleanup and only optimises each of the comparison methods; it also extends the current timestamp comparison tests to exhaustively check all permutations of any single bit, as well as a larger collection of random values that we compare exhaustively with each other (rather than only enough to sort). I will perform the class cleanup in CASSANDRA-8759 as a follow up. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[
https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312266#comment-14312266
]
J.B. Langston commented on CASSANDRA-8730:
--
[~iamaleksey] This is the schema I am testing against. It uses uuid and
timestamp (not timeuuid):
{code}
CREATE TABLE x (
a bigint,
b bigint,
c timestamp,
d uuid,
e text,
f text,
g text,
h float,
PRIMARY KEY ((a, b), c, d)
) WITH CLUSTERING ORDER BY (ts DESC, uuid DESC) AND
bloom_filter_fp_chance=0.01 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.10 AND
gc_grace_seconds=0 AND
index_interval=128 AND
read_repair_chance=0.00 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
{code}
Optimize UUIDType comparisons
-
Key: CASSANDRA-8730
URL: https://issues.apache.org/jira/browse/CASSANDRA-8730
Project: Cassandra
Issue Type: Improvement
Reporter: J.B. Langston
Assignee: Benedict
Fix For: 2.1.4
Compaction is slow on tables using compound keys containing UUIDs due to
being CPU bound by key comparison. [~benedict] said he sees some easy
optimizations that could be made for UUID comparison.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312268#comment-14312268 ] Benedict commented on CASSANDRA-8730: - [~jblangs...@datastax.com] your timestamp comparisons probably dominate; if there are only a handful of uuids per timestamp, it won't be exercised much by comparison to the timestamp comparisons Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312274#comment-14312274 ] Aleksey Yeschenko commented on CASSANDRA-8730: -- What Benedict said below. For the sake of testing this ticket, go with a simpler clustering column set - only the uuid, no timestamp. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14311330#comment-14311330 ] Benedict commented on CASSANDRA-8730: - Uploaded a new version that makes TimeUUIDType extend UUIDType, since I don't think the handful of cycles we might save with specialisation warrant the icache pollution, and future idiots like me won't make the mistake when updating one and not the other :) At the same time, I merged the fromString() behaviour to make it a bit cleaner, and in doing so noticed that the behaviour isn't consistent between the two for date-string provision. It looks to me like TimeUUID had the behaviour downgraded to CQL2 only, whereas UUID has not. I wonder if this was down to somebody else making the same mistake I did, only in reverse. [~slebresne] [~thobbs] - as CQL experts, could you enlighten on this? Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[
https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309901#comment-14309901
]
J.B. Langston commented on CASSANDRA-8730:
--
Looks like a bit of improvement: 12.63MB/sec vs 10.19MB/sec. Looks like it
threw away more data this time. I guess some tombstones passed gc grace since I
last tested. Therefore, I'm not sure how apples-to-apples the comparison is, so
I'm going to try again while setting my clock back to the date when I ran it
before.
Before:
{code}
INFO 15:19:05 Compacted 4 sstables to
[./../data/data/ocean/tbl_metric_data_dyn-0f578640a59211e4a5a2ef9f87394ca6/ocean-tbl_metric_data_dyn-ka-144263,].
9,183,829,489 bytes to 9,180,536,394 (~99% of original) in 901,172ms =
9.715395MB/s. 311,495 total partitions merged to 253,490. Partition merge
counts were {1:195485, 2:58005, }
{code}
After:
{code}
INFO 20:47:24 Completed flushing
/Users/jblangston/repos/cassandra/bin/./../data/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-ka-48-Data.db
(42 bytes) for commitlog position ReplayPosition(segmentId=1423254980101,
position=758851)
INFO 20:47:24 Compacted 4 sstables to
[./../data/data/ocean/tbl_metric_data_dyn-0f578640a59211e4a5a2ef9f87394ca6/ocean-tbl_metric_data_dyn-ka-144263,].
8,152,562,772 bytes to 4,659,100,313 (~57% of original) in 615,577ms =
7.218048MB/s. 311,495 total partitions merged to 80,012. Partition merge
counts were {1:195485, 2:58005, }
{code}
Optimize UUIDType comparisons
-
Key: CASSANDRA-8730
URL: https://issues.apache.org/jira/browse/CASSANDRA-8730
Project: Cassandra
Issue Type: Improvement
Reporter: J.B. Langston
Assignee: Benedict
Fix For: 2.1.4
Compaction is slow on tables using compound keys containing UUIDs due to
being CPU bound by key comparison. [~benedict] said he sees some easy
optimizations that could be made for UUID comparison.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309991#comment-14309991 ] Aleksey Yeschenko commented on CASSANDRA-8730: -- [~jblangs...@datastax.com] What's your schema? Does it use 'uuid' or 'timeuuid'? b/c the patch in its current form does only optimize 'uuid'. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309953#comment-14309953 ] J.B. Langston commented on CASSANDRA-8730: -- Hmm, setting my clock back didn't help. I still got the same results as before. I'm not sure why it did not compact away almost half the data before. Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Improvement Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
[ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308110#comment-14308110 ] Benedict commented on CASSANDRA-8730: - Patch available [here|https://github.com/belliottsmith/cassandra/tree/8730-uuidoptim] Optimize UUIDType comparisons - Key: CASSANDRA-8730 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730 Project: Cassandra Issue Type: Bug Reporter: J.B. Langston Assignee: Benedict Fix For: 2.1.4 Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound by key comparison. [~benedict] said he sees some easy optimizations that could be made for UUID comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
