[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969574#comment-14969574
]
T Jake Luciani commented on CASSANDRA-9975:
-------------------------------------------
That's fine/unrelated.
[~benedict] Since I'm on this ticket now some questions. Do you have any
results showing what the stack used to look like vs what it looks like now? You
mention it improves performance do we have any results to support that?
> Flatten Iterator call hierarchy with a shared Transformer
> ---------------------------------------------------------
>
> Key: CASSANDRA-9975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9975
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0.0
>
>
> Stepping through a read response is made exceedingly difficult by the sheer
> depth of the call hierarchy, and how rapidly your context jumps around. This
> ticket intend to partially address that, by flattening one of the main causes
> of this: iterator transformations.
> I have a patch that attempts to mitigate (but not entirely eliminate) this,
> through the introduction of a {{RowTransformer}} class that all
> transformations are applied through. If a transformation has already been
> applied, the {{RowTransformer}} class does not wrap a new iterator, but
> instead returns a new {{RowTransformer}} that wraps the original underlying
> (untransformed) iterator and both transformations. This can accumulate an
> arbitrary number of transformations and, quite importantly, can apply the
> filtration step {{Unfiltered -> Row}} in the same instance as well. The
> intention being that a majority of control flow happens inside this
> {{RowTransformer}}, so there is far less context jumping to cope with.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
