Numeric (and accumulators)
dl at cs.oswego.edu
Tue Sep 18 04:46:28 PDT 2012
On 09/17/12 11:40, Brian Goetz wrote:
>> One reason for integrating into j.u.c is that keyed versions of
>> these forms would need to generalize what is now LongAdderTable
> How much better (pick your metrics) is the keyed form of LAT than a CHM of
No better at all performance-wise. LAT exists/existed because
the implementations of update/get using CHM+LongAdder were
initially too messy and non-obvious.
But by adding various CHM methods over the past year,
they are getting close enough to "easy" that LAT could go away
as a class and turn into a javadoc (and/or tutorial) example.
I think that planning for it to go away is a good stance --
maybe something making it and similar constructions a bit
simpler yet will occur to us.
BTW, at some point we should discuss whether/how to support
the various CHM additions in other Map classes.
>> * Example: Maps from keys to Accumulators can be used to create
>> * (frequency maps) and related tables.
>> * To increment a count, installing if not already present:
>> * map.computeIfAbsent(key, () ->
(Actually, "k ->", not "() ->")
>> * To determine the sum for a key, it is convenient to create a
>> * singleton static EMPTY_ACCUMULATOR, enabling
>> * long sum = map.getValueOrDefault(key, EMPTY_ACCUMULATOR).get();
>> Any thoughts on this?
> Like it. Does that mean we don't need LAT at all?
More information about the lambda-libs-spec-observers