Performance Personae Cheat Sheet

[I decided this would be better if I pulled it out into its own thing: Click for the full article]

Code Persona: Inner Loop

• CPU factors dominate cost
• excellent locality required
• no tempory allocations, only direct output allocations
• threading issues handled at higher level, code is generally devoid of any kind of locking

Key metrics:

• path length — cycles per iteration
• processor cache statistics
• microbenchmarks showing (e.g.) seconds per million iterations

Code Persona: Startup

• Processor frequently not at a premium even though time is a key metric
• Working set and/or reference set dominates cost (i.e. space issues)
• limit private memory
• avoid creating new dependencies
• avoid additional external data
• avoid complex registry usage

Key metrics:

• working set information
• reference set information
• total file i/o, total disk reads
• milliseconds to initialize

Code Persona: Throughput

• steady state GC usage mode
• promotion to Generation 2 should be near nil
• low overall GC cost because of good mix of death generation
• complex calculations and/or i/o mitigated by caches with suitable policy

Key metrics:

• throughput of the activity
• GC statistics time in GC and promotion rate to gen2 or topmost)
• contention rate
• processor utilization (going for high utilization)

Code Persona: Interactive

• only small perturbations to objects to allow for brisk editing with limited/no collections
• temporary allocations permissible
• external dependencies limited, dynamic loading etc. not allowed
• object visitation proportional to the size of requested operations, cache stays hot
• processor may be entering battery conservation mode, enable via blocking

Key Metrics:

• processor utilization (going for low utilization)
• GC statistics (nil promotion rates especially)
• steady-state working set — touching little memory much can be swapped out and will not be paged back in
• dependencies checked

Data Persona: High Volume

• per object overhead plays a significant role volume may contribute to overall GC pressure
• consider value type, reference type choices carefully
• consider mutability or immutability
• consider the persona of code that will typically use the structure see data document rules
• choose storage-oriented data structures not abstraction oriented ones

Key Metrics:

• size per object
• overhead per object
• cache lines touched per operation

Data Persona: Document

• highlighted by significant size and durability of the document as well as value of the data
• incremental operations common, operations generally mutate the document
• locality of the document pieces is vital to success
• incremental operations should touch a minimum of memory
• similarly aged objects should be involved in logical operations — do not frequently cause old objects to point to new as this is bad for the GC
• documents must have clear “unit of work”
• threading issues should be either explicitly excluded or else designed in clearly
• isolation and transactional policy must be described
• Visibility of changes across threads? Out of memory cases?
• Recovery from fatal errors?
• consider searching as a key scenario for document data

Key Metrics:

• Size to represent typical documents
• Waste bytes (pointer overheads etc.) for typical documents
• Overhead associated with typical “transactions”

Data Persona: Cache

• cache policy is the key decision — what to keep what to discard
• most times weak references in the cache indicate a problem -> policy should drive discard choices not the GC
• if the cache starts to feel like a document it is likely not doing its job
• cache policies should include right-sizing logic to create an effective cache
• hit rates and other metrics should be readily observable for important caches

Key Metrics:

• Typical cache sizes (representative cases)
• Hit rate vs. size of cache (bytes)
• Throughput of representative algorithms vs. size of cache