RFR: updated draft API for JEP 269 Convenience Collection Factories

[Michael Hixson]

Hi Stuart,

I don't know if I have any new information to add.  When I try to
solve this equation, I:

- Look at the difference between fixed-arg and non-optimized varargs
from my benchmarks (allocating an array doesn't get faster with JIT
optimizations, does it?), which is on the order of tens of nanoseconds
per call with my semi-modern desktop hardware
- Make an estimate about how many times a program will call these
methods during initialization... let's say 1000 (which sounds like a
pathological case to me, but possible)
- Multiply the two and estimate I'd be adding tens of microseconds to
startup time (given *today's* semi-modern desktop hardware)
- Multiply that by the percentage of programs I think care about that
amount of startup time (which eliminates just about everything I've
worked on; I make long-running server-side web apps for a living)
- Attempt to weigh that against the totally subjective cost of 10 new,
functionally redundant static methods in the List and Set APIs

I'd fall on the side of not adding the overloads.  But you already
knew that, and I'm not the one trusted with making that judgment call.
:)

It's a minor issue either way.  The overloads are more academically
offensive than practically harmful.

-Michael

On Mon, Nov 9, 2015 at 12:44 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi Michael, Peter,
>
> I admit to not having followed all the benchmarking discussion (travel,
> Devoxx) but I did want to respond to this:
>
> Peter wrote:
>>
>> So it looks like that there's no need to burden the public API with
>> explicit argument overloads.
>
>
> These are JMH benchmarks, which take care to warm up the JIT, so that
> everything is nicely optimized, inlined, escape-analyzed, etc., right?
>
> If so, I don't see this at all being representative of how these APIs will
> be used. They won't be called in tight loops that give the JVM a chance to
> optimize them. Instead, they'll be used for initializing fields, including
> static fields:
>
>     class MyClass {
>         static final Set<String> set = Set.of("a", "b", "c");
>         ...
>     }
>
> This call to Set.of() will (probably) be called exactly once when MyClass is
> loaded. It'll probably be run in interpretive mode. If the API becomes
> popular, there will be lots of calls like this in static initializers and
> instance initializers. Most of these will be called once or relatively few
> times, but there may be a lot of such calls. I think most of these would be
> run by the interpreter.
>
> How do we assess the impact of fixed-args vs varargs overloads for cases
> like this?
>
> s'marks
>