1. FP and Performance
Beyond Big
“O” Notation
Jamie Allen
Director of Consulting

2. Who Am I?
• Director of
Consulting for
• Author of
Effective Akka
@jamie_allen
2

3. Big “O” Notation
3

4. Many Developers Don’t Look Further
4

5. Reactive Applications
5

6. What is Performance?
Latency
Throughput
Footprint
6

7. Power Consumption!
7

8. There are no standards
The only rules you must follow is your
non-functional requirements!
8

9. We Love Functional Programming!
• But what is it?
•Just first class functions?
•Referential transparency?
•Immutability?
•Category theory?
9

10. Abstractions!
• They help us
reason about
our logic
• Decoupling
• Simplicity
• Correctness
• Reuse
10

11. Double Edged Sword
• We live in a world of abstractions
already!
•Languages on the JVM are DSL for bytecode
•Bytecode is an abstraction over macro
instructions
•Macro instructions are an abstraction over
micro instructions
11

12. JVM == Imperative
• The JVM is built to execute imperative
logic very fast
• The more we stray from imperative logic
constructs, the more we pay in terms of
performance
12

13. Penalties
• Increased allocations
• More bytecode executed to perform
tasks
• Less control over runtime performance
13

14. There Is A Fine Line Here
• We love to write “elegant” code, but this
is defined by your personal aesthetic
•Some people love prefix notation and sexpressions
•Some people see beauty in c-style constructs
14

15. Rap Genius
15

16. What About The Environment?
16

17. We Can’t Ignore the Cost!
17

18. Languages Impose Constraints
• “Choose-a-phone” languages versus those
with strictly defined language constructs
18

19. Languages “Pick” Abstractions For You
• Example: CSP versus Actor models
•Why must we choose?
•Why can’t we have both in libraries?
•Why can’t both be relevant to solving
problems in an application?
19

20. We Need to be Treated Like Adults!
• Every program will behave differently
• Choosing a language that imposes strict
rules forces us to make ugly choices
20

21. How Many Libs Have Performance
Tests?
• Very few
• You give up
control of your
ability to optimize
when you use
libraries
21

22. Asynchrony
• A wonderful tool for leveraging cores on
a machine
• Not faster than a single thread per se
• We must pay attention to Amdahl’s Law
22

23. Hardware
From the bottom up, computers
understand queues and message passing
23

24. Things to Avoid
• Parallel Collections
• STM
• Returns out of closures
• Boxing
• Lambdas! :)
24

25. Digression: Don’t Use OSX
• It’s lousy for doing performance analysis
• The JVM has issues, particularly with
visibility
25

26. Tools Also Have Issues
• Many tools only give you information
after the JVM is at a safepoint
• What does that tell us about our memory
consumption or thread stacks?
26

27. Tools That I Trust
•
•
•
•
jHiccup (pauses and stalls)
Java Microbenchmarking Harness
PrintGCStats (post-mortem tool on GC output in file)
GC:
• jClarity Censum
• GarbageCat
• VisualVM with Visual GC plugin
• htop (visualize user vs kernel usage)
• dstat (replaces vmstat, iostat and ifstat)
• --cpu, --mem, --aio, --top-io, --top-bio
• OProfile (system wide Linux profiler)
27

28. Pinning to Cores
• Use numactl for pinning to cores and
sockets
• taskset pins to cores only, no control
over cross-socket communication, which
has latency penalties, but useful for
laptop tests
28

29. JVM Flags to Use
• Pay close attention to the output from:
• +PrintGCDetails
• +PrintGCDateStamp
• +PrintGCCause
• +PrintGCApplicationStoppedTime
• +PrintTenuringDistribution (age of objects in survivor
spaces)
• +PrintSafepointStatistics (reason and timings)
• +PrintFlagsFinal (show entire JVM config)
• +PrintAssembly (must use
+UnlockDiagnosticVMOptions)
29

30. Don’t Overuse Memory Barriers
• Volatile variables aren’t required for
every field
• Think about how to organize updates to
fields and then update ONE volatile var
last to publish all
30

31. Thank You!
31