Spliterator implementations (original) (raw)
Doug Lea dl at cs.oswego.edu
Wed Jan 2 17:09:04 PST 2013
- Previous message: Spliterator implementations
- Next message: Spliterator implementations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 01/02/13 18:58, Brian Goetz wrote:
From your list, there are a few that might benefit enough from a better implementation to be worth the effort, such as Enum{Set,Map}, {Hash,Tree,LinkedHash}{Set,Map}. For most of the rest (and some of these, probably), the Iterator version is probably good enough.
We'd need to document goodness (or good-enough-ness) in the same way we document other algorithmic properties of JDK collections. For anything hopelessly listy (almost all queues, LinkedList, LinkedHashSet, etc) we'd want to clearly indicate O(n) splitting that would be worthwhile only if each function application to each element is very expensive. Not documenting these will surely lead to justifiable bug reports.
Conversely most array-based ones (including most hash tables) can document best-case O(n/p) performance (p is parallelism level) because of constant split time. Others somewhere in the middle. Of those others, there may be those that could in principle be faster but might not be for JDK8 ship?
-Doug
- Previous message: Spliterator implementations
- Next message: Spliterator implementations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list