[
https://issues.apache.org/jira/browse/TINKERPOP-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15191011#comment-15191011
]
ASF GitHub Bot commented on TINKERPOP-1180:
-------------------------------------------
Github user okram commented on a diff in the pull request:
https://github.com/apache/incubator-tinkerpop/pull/254#discussion_r55836702
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/sideEffect/GroupSideEffectStep.java
---
@@ -77,7 +77,7 @@ public void modulateBy(final Traversal.Admin<?, ?>
kvTraversal) {
@Override
protected void sideEffect(final Traverser.Admin<S> traverser) {
- final Map<K, Object> map = new HashMap<>();
+ final Map<K, Object> map = new HashMap<>(1);
--- End diff --
That line of code is as you have it in master/. Was done in another PR.
Also, the load factor can't be 1.0 as that map will presumably grow on
reduction.
> Add more optimized binary operators to Operator.
> ------------------------------------------------
>
> Key: TINKERPOP-1180
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1180
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.1-incubating
> Reporter: Marko A. Rodriguez
>
> We currently have {{Operator}} enum which has nice operators like {{add}},
> {{assign}}, {{sum}}, {{max}}, {{min}}, etc. The problem with lots of the
> number-based implementations is that they reason about the number format
> using {{NumberHelper}}. I think we should add {{sumLong}}, {{sumInteger}},
> and the like to allow classes the leverage {{Operator}} to bypass
> number-type-reasoning when they know it will be a long, integer, etc.
> This is important for {{GraphComputer.Memory}} where reducers are binary
> operators and we use {{Operator}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
