performance-smell-detection

Name: performance-smell-detection
Author: decebals

686stars133forks

How to install performance-smell-detection?

decebals/claude-code-java/performance-smell-detection

$npx -y skills add decebals/claude-code-java --skill performance-smell-detection

Installs into the current project.

Summary

Detect potential code-level performance smells in Java - streams, collections, boxing, regex, object creation. Provides awareness, not absolutes - always measure before optimizing. For JPA/database performance, use jpa-patterns instead.

Files · 1

View on GitHub

SKILL.md

1	# Performance Smell Detection Skill
2
3	Identify potential code-level performance issues in Java code.
4
5	## Philosophy
6
7	> "Premature optimization is the root of all evil" - Donald Knuth
8
9	This skill helps you notice potential performance smells, not blindly "fix" them. Modern JVMs (Java 21/25) are highly optimized. Always:
10
11	1. Measure first - Use JMH, profilers, or production metrics
12	2. Focus on hot paths - 90% of time spent in 10% of code
13	3. Consider readability - Clear code often matters more than micro-optimizations
14
15	## When to Use
16	- Reviewing performance-critical code paths
17	- Investigating measured performance issues
18	- Learning about Java performance patterns
19	- Code review with performance awareness
20
21	## Scope
22
23	This skill: Code-level performance (streams, collections, objects)
24	For database: Use `jpa-patterns` skill (N+1, lazy loading, pagination)
25	For architecture: Use `architecture-review` skill
26
27	---
28
29	## Quick Reference: Potential Smells
30
31	\| Smell \| Severity \| Context \|
32	\|-------\|----------\|---------\|
33	\| Regex compile in loop \| 🔴 High \| Always worth fixing \|
34	\| String concat in loop \| 🟡 Medium \| Still valid in Java 21/25 \|
35	\| Stream in tight loop \| 🟡 Medium \| Depends on collection size \|
36	\| Boxing in hot path \| 🟡 Medium \| Measure first \|
37	\| Unbounded collection \| 🔴 High \| Memory risk \|
38	\| Missing collection capacity \| 🟢 Low \| Minor, measure if critical \|
39
40	---
41
42	## String Operations (Java 9+ / 21 / 25)
43
44	### What Changed
45
46	Since Java 9 (JEP 280), string concatenation with `+` uses `invokedynamic`, not StringBuilder. The JVM optimizes simple concatenation well.
47
48	Java 25 adds String::hashCode constant folding for additional optimization in Map lookups with String keys.
49
50	### Still Valid: StringBuilder in Loops
51
52	```java
53	// 🔴 Still problematic - new String each iteration
54	String result = "";
55	for (String s : items) {
56	result += s; // O(n²) - creates n strings
57	}
58
59	// ✅ StringBuilder for loops
60	StringBuilder sb = new StringBuilder();
61	for (String s : items) {
62	sb.append(s);
63	}
64	String result = sb.toString();
65
66	// ✅ Or use String.join / Collectors.joining
67	String result = String.join("", items);
68	```
69
70	### Now Fine: Simple Concatenation
71
72	```java
73	// ✅ Fine in Java 9+ - JVM optimizes this
74	String message = "User " + name + " logged in at " + timestamp;
75
76	// ✅ Also fine
77	return "Error: " + code + " - " + description;
78	```
79
80	### Avoid in Hot Paths: String.format
81
82	```java
83	// 🟡 String.format has parsing overhead
84	log.debug(String.format("Processing %s with id %d", name, id));
85
86	// ✅ Parameterized logging (SLF4J)
87	log.debug("Processing {} with id {}", name, id);
88	```
89
90	---
91
92	## Stream API (Nuanced View)
93
94	### The Reality
95
96	Streams have overhead, but it's often acceptable:
97	- < 100 items: Streams can be 2-5x slower (but still microseconds)
98	- 1K-10K items: Difference narrows significantly
99	- > 10K items: Often within 50% of loops
100	- GraalVM: Can optimize streams to match loops
101
102	Recommendation: Prefer streams for readability. Optimize to loops only when profiling shows a bottleneck.
103
104	### When Streams Are Problematic
105
106	```java
107	// 🔴 Stream created per iteration in hot loop
108	for (int i = 0; i < 1_000_000; i++) {
109	boolean found = items.stream()
110	.anyMatch(item -> item.getId() == i);
111	}
112
113	// ✅ Pre-compute lookup structure
114	Set<Integer> itemIds = items.stream()
115	.map(Item::getId)
116	.collect(Collectors.toSet());
117
118	for (int i = 0; i < 1_000_000; i++) {
119	boolean found = itemIds.contains(i);
120	}
121	```
122
123	### When Streams Are Fine
124
125	```java
126	// ✅ Single pass, readable, not in tight loop
127	List<String> names = users.stream()
128	.filter(User::isActive)
129	.map(User::getName)
130	.sorted()
131	.collect(Collectors.toList());
132
133	// ✅ Primitive streams avoid boxing
134	int sum = numbers.stream()
135	.mapToInt(Integer::intValue)
136	.sum();
137	```
138
139	### Parallel Streams: Use Carefully
140
141	```java
142	// 🔴 Parallel on small collection - overhead > benefit
143	smallList.parallelStream().map(...); // < 10K items
144
145	// 🔴 Parallel with shared mutable state
146	List<String> results = new ArrayList<>();
147	items.parallelStream()
148	.forEach(results::add); // Race condition!
149
150	// ✅ Parallel for CPU-intensive + large collections
151	List<Result> results = largeDataset.parallelStream() // > 10K items
152	.map(this::expensiveCpuComputation)
153	.collect(Collectors.toList());
154	```
155
156	---
157
158	## Boxing/Unboxing
159
160	### Still a Real Issue
161
162	Boxing creates objects on heap, adds GC pressure. JVM caches small values (-128 to 127) but not larger ones.
163
164	> Future: Project Valhalla will improve this significantly.
165
166	```java
167	// 🔴 Boxing in tight loop - creates millions of objects
168	Long sum = 0L;
169	for (int i = 0; i < 1_000_000; i++) {
170	sum += i; // Unbox, add, box
171	}

People who liked this also viewed

6 picks

Type

performance-smell-detection

686stars133forks

View on GitHub

How to install performance-smell-detection?

decebals/claude-code-java/performance-smell-detection

$npx -y skills add decebals/claude-code-java --skill performance-smell-detection

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Performance Smell Detection Skill
2
3	Identify potential code-level performance issues in Java code.
4
5	## Philosophy
6
7	> "Premature optimization is the root of all evil" - Donald Knuth
8
9	This skill helps you notice potential performance smells, not blindly "fix" them. Modern JVMs (Java 21/25) are highly optimized. Always:
10
11	1. Measure first - Use JMH, profilers, or production metrics
12	2. Focus on hot paths - 90% of time spent in 10% of code
13	3. Consider readability - Clear code often matters more than micro-optimizations
14
15	## When to Use
16	- Reviewing performance-critical code paths
17	- Investigating measured performance issues
18	- Learning about Java performance patterns
19	- Code review with performance awareness
20
21	## Scope
22
23	This skill: Code-level performance (streams, collections, objects)
24	For database: Use `jpa-patterns` skill (N+1, lazy loading, pagination)
25	For architecture: Use `architecture-review` skill
26
27	---
28
29	## Quick Reference: Potential Smells
30
31	\| Smell \| Severity \| Context \|
32	\|-------\|----------\|---------\|
33	\| Regex compile in loop \| 🔴 High \| Always worth fixing \|
34	\| String concat in loop \| 🟡 Medium \| Still valid in Java 21/25 \|
35	\| Stream in tight loop \| 🟡 Medium \| Depends on collection size \|
36	\| Boxing in hot path \| 🟡 Medium \| Measure first \|
37	\| Unbounded collection \| 🔴 High \| Memory risk \|
38	\| Missing collection capacity \| 🟢 Low \| Minor, measure if critical \|
39
40	---
41
42	## String Operations (Java 9+ / 21 / 25)
43
44	### What Changed
45
46	Since Java 9 (JEP 280), string concatenation with `+` uses `invokedynamic`, not StringBuilder. The JVM optimizes simple concatenation well.
47
48	Java 25 adds String::hashCode constant folding for additional optimization in Map lookups with String keys.
49
50	### Still Valid: StringBuilder in Loops
51
52	```java
53	// 🔴 Still problematic - new String each iteration
54	String result = "";
55	for (String s : items) {
56	result += s; // O(n²) - creates n strings
57	}
58
59	// ✅ StringBuilder for loops
60	StringBuilder sb = new StringBuilder();
61	for (String s : items) {
62	sb.append(s);
63	}
64	String result = sb.toString();
65
66	// ✅ Or use String.join / Collectors.joining
67	String result = String.join("", items);
68	```
69
70	### Now Fine: Simple Concatenation
71
72	```java
73	// ✅ Fine in Java 9+ - JVM optimizes this
74	String message = "User " + name + " logged in at " + timestamp;
75
76	// ✅ Also fine
77	return "Error: " + code + " - " + description;
78	```
79
80	### Avoid in Hot Paths: String.format
81
82	```java
83	// 🟡 String.format has parsing overhead
84	log.debug(String.format("Processing %s with id %d", name, id));
85
86	// ✅ Parameterized logging (SLF4J)
87	log.debug("Processing {} with id {}", name, id);
88	```
89
90	---
91
92	## Stream API (Nuanced View)
93
94	### The Reality
95
96	Streams have overhead, but it's often acceptable:
97	- < 100 items: Streams can be 2-5x slower (but still microseconds)
98	- 1K-10K items: Difference narrows significantly
99	- > 10K items: Often within 50% of loops
100	- GraalVM: Can optimize streams to match loops
101
102	Recommendation: Prefer streams for readability. Optimize to loops only when profiling shows a bottleneck.
103
104	### When Streams Are Problematic
105
106	```java
107	// 🔴 Stream created per iteration in hot loop
108	for (int i = 0; i < 1_000_000; i++) {
109	boolean found = items.stream()
110	.anyMatch(item -> item.getId() == i);
111	}
112
113	// ✅ Pre-compute lookup structure
114	Set<Integer> itemIds = items.stream()
115	.map(Item::getId)
116	.collect(Collectors.toSet());
117
118	for (int i = 0; i < 1_000_000; i++) {
119	boolean found = itemIds.contains(i);
120	}
121	```
122
123	### When Streams Are Fine
124
125	```java
126	// ✅ Single pass, readable, not in tight loop
127	List<String> names = users.stream()
128	.filter(User::isActive)
129	.map(User::getName)
130	.sorted()
131	.collect(Collectors.toList());
132
133	// ✅ Primitive streams avoid boxing
134	int sum = numbers.stream()
135	.mapToInt(Integer::intValue)
136	.sum();
137	```
138
139	### Parallel Streams: Use Carefully
140
141	```java
142	// 🔴 Parallel on small collection - overhead > benefit
143	smallList.parallelStream().map(...); // < 10K items
144
145	// 🔴 Parallel with shared mutable state
146	List<String> results = new ArrayList<>();
147	items.parallelStream()
148	.forEach(results::add); // Race condition!
149
150	// ✅ Parallel for CPU-intensive + large collections
151	List<Result> results = largeDataset.parallelStream() // > 10K items
152	.map(this::expensiveCpuComputation)
153	.collect(Collectors.toList());
154	```
155
156	---
157
158	## Boxing/Unboxing
159
160	### Still a Real Issue
161
162	Boxing creates objects on heap, adds GC pressure. JVM caches small values (-128 to 127) but not larger ones.
163
164	> Future: Project Valhalla will improve this significantly.
165
166	```java
167	// 🔴 Boxing in tight loop - creates millions of objects
168	Long sum = 0L;
169	for (int i = 0; i < 1_000_000; i++) {
170	sum += i; // Unbox, add, box
171	}

People who liked this also viewed

6 picks

Type