[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711633#comment-14711633
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
We aren't optimising {{compareComponent}}. That would imply this ticket is
sneaking in some positive changes\*, when in fact it is simply avoiding
introducing a negative one. The prior behaviour had one inlining; this would
have resulted in two, and a dramatic increase in the size of the method.
Now, it may be that if we were to measure the effect it would be hard to do so.
However that would itself be largely down to the fact we _never consider these
effects_. Death by a thousand papercuts. Stemming the blood flow from one
papercut doesn't do much. As such I cannot personally subscribe to an ethos of
kicking down the road at least a reasonable consideration of the effects of a
change I'm actively making.
Certainly, if the code were significantly ungainly as a result, investigation
and a follow up ticket might be necessary. Here, the code is just 100% fine,
with barely the faintest hint of ugliness, and the "benefit" (i.e.
non-detriment) was likely (and demonstrated). I cannot fathom why it should
spawn such discussion.
\*In fact it does sneak in a small improvement, by forcing a conversion to
{{ImmutableList}} in the constructor to permit efficient despatch for the list
get method. However this was not picked out for censure, despite _actually_
falling into the category of unrelated optimisation. Go figure.
> Make AbstractType.isByteOrderComparable abstract
> ------------------------------------------------
>
> Key: CASSANDRA-9901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9901
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0 beta 2
>
> Attachments: C2 compilation output
>
>
> I can't recall _precisely_ what was agreed at the NGCC, but I'm reasonably
> sure we agreed to make this method abstract, put some javadoc explaining we
> may require fields to yield true in the near future, and potentially log a
> warning on startup if a user-defined type returns false.
> This should make it into 3.0, IMO, so that we can look into migrating to
> byte-order comparable types in the post-3.0 world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
