估计连续Spliterator上的大小（）

我正在实施Spliterator明确限制并行化的trySplit()返回null。执行estimateSize()是否会为此分割器生成的流提供任何性能改进？或者估计的大小只对并行化有用？估计连续Spliterator上的大小（）

编辑：为了澄清，我具体询问估计大小。换句话说，我的分割器没有SIZED特性。

来源

2015-06-07 shmosel

至少toArray方法将使用估计的大小;合理准确的估计可能会减少复制。 –

查看调用层次结构相关spliterator特征表明，它至少相关stream.toArray()性能

enter image description here

此外，还有内部流实现等效的标志，似乎是用来排序：

enter image description here

所以除了并行流操作外，大小估计似乎被用于这两种操作。

我没有为我的搜索要求详尽，所以只要拿这些作为例子。

不施胶特点我只能找到estimateSize()是相关的流管道并行执行调用。

当然，这可能会在将来或另一个Stream实现中发生变化，而不是标准JDK的行为可能会有所不同。

来源

2015-06-07 09:56:05 the8472

澄清了我的问题。 – shmosel

在这种情况下，它似乎只用于并行执行 – the8472

那么，最重要的句子是最后一句：“*当然这可能会改变在未来或另一个Stream实现比标准的JDK可以有不同的行为*”，值得+1。还应该注意的是，其他库也可能直接访问“Spliterator”并获得这样的功能。这就是为什么总是建议针对*合同*进行编程的原因，而不是当前的实施。 – Holger

甲spliterator可以遍历元素：

1.Individually（tryAdvance()）

2.Sequentially散装（forEachRemaining()）

作为每java docsestimateSize()分裂期间来得心应手。

通过estimateSize（）方法，Spliterators可以提供估计剩余的元素的数量。理想情况下，如特性SIZED所示，该值完全对应于将在成功遍历中遇到的元素的数量。 然而，即使当未完全知道时，估计值值仍然可以是对在源上执行的操作有用的，例如帮助确定是进一步分割还是沿着顺序遍历其余元素。

因为你spliterator没有施胶特征estimateSize将不提供任何性能（因为没有并行的），但是请记住，estimateSize Java的文档没有提到并行的东西，所有它指出是：

返回：估计大小，或Long.MAX_VALUE（如果无限，未知，或计算太昂贵）。

来源

2015-06-07 09:27:00 sol4me

粗体部分给出的唯一例子是确定是否可以进一步分割。分裂只用于并行流，OP会明确拒绝，因此是问题。 –

估计连续Spliterator上的大小（）

回答

相关问题