cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9901) Make AbstractType.isByteOrderComparable abstract
Date Tue, 25 Aug 2015 17:03:45 GMT


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:
>             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
> 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

View raw message