London Lambdas Hackday: Performance and Parallelism

[Brian Goetz]

> They didn't profile, they guessed what the bottleneck in their program
> was.  This will definitely happen in real life development scenarios,
> and I don't think many people even have sensible rules of thumb.  With
> hindsight I should have surveyed the room to find out what percentage
> of developer's knew what Amdahl's Law was, but nevermind.  They key
> point is that when you make parallelism easy to obtain people will
> attempt it without considering the consequences of their actions.

This is definitely true.  Our goal here is make it easy to collect the 
low-hanging fruit; get 80% of the benefit for 5% of the work.  But, you 
still have to do *some* work -- you have to know something about the 
collection that is the source of your data, for example.

> 2. What is the decomposition model of parallel()?
>
> This isn't obvious from the documentation.  Is there a cost model for
> splitting things up?  Can people easily figure out a computational
> cost budget between different components and work out at what point
> there's a benefit to parallelism?

Each collection should document something about its decomposition 
behavior, just as it does its iteration behavior.  The default 
decomposition will be pretty bad; we'll be lucky to not get negative 
speedup from parallelism on, say, a LinkedList.  Specific collection 
classes like ArrayList or TreeSet will provide a better decomposition.

> 3. Readability of Profiling
>
> If you profile for execution time then you may hit a scenario where a
> lot of your CPU time is begin eaten by a lambda.  In the build 45
> implementation these were being compiled as anonymous inner classes,
> which won't be the final strategy but it meant I couldn't really
> experiment with profiling.  What will a lambda method look like when
> displayed in a profiler?  Have you figured out a method naming
> convention?

It will be a method in the capturing class named lambda$nnn.