[
https://issues.apache.org/jira/browse/CASSANDRA-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024428#comment-15024428
]
Benjamin Lerer commented on CASSANDRA-10409:
--------------------------------------------
{quote}Modulo the inlining of getColumnDefs(), the change just replaces
restrictions.keySet().size() by restrictions.size() so the change made by the
patch is, I'm pretty confident, strictly equivalent to what was done
before{quote}
My mistake.
> 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
> Priority: Minor
> Labels: performance
> 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)
