hg: lambda/lambda/jdk: 3 new changesets
Rémi Forax
forax at univ-mlv.fr
Wed May 30 16:26:42 PDT 2012
On 05/31/2012 12:11 AM, Brian Goetz wrote:
>> I don't like the class StringJoiner because despite the fact it's a
>> reduce operation,
>> it's implemented as a Fillable, so something eager which will not work
>> as is in the parallel world.
>
> That's where we started -- trying to treat string joining as a reduce.
> But because String is immutable, doing a sequential reduce with string
> concatenation becomes an O(n^2) operation, which is not good.
>
> (Originally we thought that the way to do joining was:
> stream.interleaveWith(Streams.repeating(", "))
> .reduce(String::concatenate)
> but the reduce step, which, while pretty, was inefficient.)
join is a kind reduce operation that can be easily be implemented as a
foldLeft
on a StringBuilder.
collection.foldLeft(new StringBuilder(),
(element, builder) -> {
if (builder.length == 0)
return builder.append(element);
return builder.append(", ").append(element);
}).toString()
for the parallel case, the question is how to implement foldLeft ?
perhaps foldLeft should return an Iterable of StringBuilder() that you can
reduce sequentially afterward.
>
> The parallel case isn't much better. Even if you do a number of
> string joins at the leaves of the tree, the top-level combine still
> has to copy all the string content, which loses most of the parallelism.
>
> But you can still do upstream ops in parallel:
>
> collection.parallel()
> .filter(...)
> .map(...)
> .sorted()
> .sequential()
> .into(new StringJoiner(", "));
>
> and all the upstream stuff will happen in parallel.
>
>> I think it's better to add join() on Iterable.
>
> Would like to, but we can't add methods that only apply to specific
> parameterizations.
you don't have to because all objects have a method toString()
or said in another way StringBuilder.append() takes an Object as parameter.
cheers,
Rémi
More information about the lambda-dev
mailing list