In fact, default spliterator created from Iterator tries to split data anyway (using buffering and assuming, that producing values is faster than processing, which is reasonable assumption).
We put our implementation inside VirtualList and IntRange, but it is unnecessary to put it everywhere, especially because our data structures are not designed for parallelization in first place, I suppose.
They are fast, sequential, memory bounded, designed for realtime constraints, not for parallel processing which introduces a lot of overhead anyway.
In fact, default spliterator created from Iterator tries to split data anyway (using buffering and assuming, that producing values is faster than processing, which is reasonable assumption).
We put our implementation inside VirtualList and IntRange, but it is unnecessary to put it everywhere, especially because our data structures are not designed for parallelization in first place, I suppose.
They are fast, sequential, memory bounded, designed for realtime constraints, not for parallel processing which introduces a lot of overhead anyway.
At this moment, our collections do not support parallel spliterators.
Especially
VirtualListandIntRangeshould return specialized spliterators.In fact, default spliterator created from Iterator tries to split data anyway (using buffering and assuming, that producing values is faster than processing, which is reasonable assumption).
We put our implementation inside VirtualList and IntRange, but it is unnecessary to put it everywhere, especially because our data structures are not designed for parallelization in first place, I suppose.
They are fast, sequential, memory bounded, designed for realtime constraints, not for parallel processing which introduces a lot of overhead anyway.