[jira] [Commented] (CASSANDRA-10409) Specialize MultiCBuilder when building a single clustering

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-10409:
----------------------------------------------

Pushed a patch for this [here|https://github.com/pcmanus/cassandra/commits/10409] (with 2 commits: the first one is the main patch, the 2nd one is a trivial optimization of {{BTreeSet}} singleton constructor (which is particularly used by the new specialization)).

> Specialize MultiCBuilder when building a single clustering
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-10409
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10409
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 3.x
>
>
> {{MultiCBuilder}} is used to build the {{Clustering}} and {{Slice.Bound}} used by  queries. As the name implies, it's able to build multiple {{Clustering}}/{{Slice.Bound}} for when we have {{IN}}, but most queries don't use {{IN}} and in this (frequent) case, {{MultiCBuilder}} creates quite a bit more objects that would be necessary (it creates 2 lists for its {{elementsList}}, then a {{CBuilder}} and a {{BTreeSet.Builder}} (even though we know the resulting set will have only one element in this case)). Without being huge, this does show up as non entirely negligible when profiling some simple stress.
> We can easily know if the query has a {{IN}} and so we can know when only a single {{Clustering}}/{{Slice.Bound}} is built, and we can specialize the implementation in that case to be less wasteful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)