Identify potential code-level performance issues - with nuance, not absolutes
Helps notice potential performance smells in Java code:
- Stream API usage patterns
- Boxing/unboxing overhead
- Regex compilation costs
- Collection inefficiencies
- String operations
Philosophy: "Measure first, optimize second" - modern JVMs are highly optimized.
- "Check for performance issues"
- "Review this hot path"
- "Is this code efficient?"
- Investigating measured slowness
This skill accounts for modern Java optimizations:
| Topic | Java 9+ Change |
|---|---|
String + |
Uses invokedynamic, well optimized outside loops |
| StringBuilder | Still best for loops |
| Virtual Threads | Java 21+ for I/O-bound work |
| String hashCode | Java 25 constant folding |
| Level | Meaning | Action |
|---|---|---|
| 🔴 High | Usually worth fixing | Fix proactively |
| 🟡 Medium | Measure first | Profile before changing |
| 🟢 Low | Nice to have | Only if critical path |
- Strings - Concatenation in loops (still valid concern)
- Streams - Overhead in tight loops, parallel misuse
- Boxing - Primitive wrappers in hot paths
- Regex - Pattern.compile in loops
- Collections - Wrong type, unbounded queries
- Modern patterns - Virtual threads, structured concurrency
- JPA/Database - Use
jpa-patternsskill - Architecture - Use
architecture-reviewskill - JVM tuning - Out of scope (GC, heap, etc.)
You: Check this code for performance issues
Claude: [Identifies potential smells]
[Rates severity: 🔴/🟡/🟢]
[Recommends measuring before changing]
[Suggests modern alternatives if applicable]
jpa-patterns- Database performance (N+1, pagination)java-code-review- General code qualityconcurrency-review- Thread safety and async patterns