cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9985) Introduce our own AbstractIterator
Date Thu, 06 Aug 2015 10:50:04 GMT


Benedict commented on CASSANDRA-9985:

bq. Can I bring up the icache boogyman? 

You can. Since I'm it's main champion, it's a powerful weapon against me. However in this
case a little analysis shows that Guava doesn't even use its own {{AbstractIterator}} (either
of them!) very much at all. In fact nowhere that we do, from what I can tell. I believe CASSANDRA-9471
uses {{Iterables.mergeSorted}} which does - but we can perform a more efficient merge since
it's only 2-way, and otherwise should prefer our own Mergeiterator, which has a more efficient
heap implementation. So I will update it to avoid using this function.

Which is a relief, since I am not in favour of overriding external packages if we can avoid
it, as it plays havoc with anyone wanting to use signed jars.

The only other place we use Guava {{AbstractIterator}} is in OHC. Since this is the "HotKey"
iterator, it is used infrequently and probably not to be troubled over.

Of course, we do run the risk of in future introducing the occasional usage, but those risks
are small given how narrowly it is deployed in Guava. We have a lot of minor issues around
duplication, and we should probably file a ticket to specifically track and fix it en masse.
Especially regarding duplicate functionality between Guava and java.util.function, but no
harm setting up some analysis for everything. It would be great if we had some automated analysis
to tell us of duplicate code candidates, in general. I'm certain such tools exist.

I'll take a look at purloining any Guava tests.

> Introduce our own AbstractIterator
> ----------------------------------
>                 Key: CASSANDRA-9985
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Trivial
>             Fix For: 3.0.0 rc1
> The Guava AbstractIterator not only has unnecessary method call depth, it is difficult
to debug without attaching source. Since it's absolutely trivial to write our own, and it's
used widely within the codebase, I think we should do so.

This message was sent by Atlassian JIRA

View raw message