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.
npx skills add https://github.com/decebals/claude-code-java --skill performance-smell-detection
Identify potential code-level performance issues in Java code.
> "Premature optimization is the root of all evil" - Donald Knuth
This skill helps you notice potential performance smells, not blindly "fix" them. Modern JVMs (Java 21/25) are highly optimized. Always:
This skill: Code-level performance (streams, collections, objects)
For database: Use jpa-patterns skill (N+1, lazy loading, pagination)
For architecture: Use architecture-review skill
| Smell | Severity | Context |
|-------|----------|---------|
| Regex compile in loop | 🔴 High | Always worth fixing |
| String concat in loop | 🟡 Medium | Still valid in Java 21/25 |
| Stream in tight loop | 🟡 Medium | Depends on collection size |
| Boxing in hot path | 🟡 Medium | Measure first |
| Unbounded collection | 🔴 High | Memory risk |
| Missing collection capacity | 🟢 Low | Minor, measure if critical |
Since Java 9 (JEP 280), string concatenation with + uses invokedynamic, not StringBuilder. The JVM optimizes simple concatenation well.
Java 25 adds String::hashCode constant folding for additional optimization in Map lookups with String keys.
// 🔴 Still problematic - new String each iteration
String result = "";
for (String s : items) {
result += s; // O(n²) - creates n strings
}
// ✅ StringBuilder for loops
StringBuilder sb = new StringBuilder();
for (String s : items) {
sb.append(s);
}
String result = sb.toString();
// ✅ Or use String.join / Collectors.joining
String result = String.join("", items);
// ✅ Fine in Java 9+ - JVM optimizes this
String message = "User " + name + " logged in at " + timestamp;
// ✅ Also fine
return "Error: " + code + " - " + description;
// 🟡 String.format has parsing overhead
log.debug(String.format("Processing %s with id %d", name, id));
// ✅ Parameterized logging (SLF4J)
log.debug("Processing {} with id {}", name, id);
Streams have overhead, but it's often acceptable:
Recommendation: Prefer streams for readability. Optimize to loops only when profiling shows a bottleneck.
// 🔴 Stream created per iteration in hot loop
for (int i = 0; i < 1_000_000; i++) {
boolean found = items.stream()
.anyMatch(item -> item.getId() == i);
}
// ✅ Pre-compute lookup structure
Set<Integer> itemIds = items.stream()
.map(Item::getId)
.collect(Collectors.toSet());
for (int i = 0; i < 1_000_000; i++) {
boolean found = itemIds.contains(i);
}
// ✅ Single pass, readable, not in tight loop
List<String> names = users.stream()
.filter(User::isActive)
.map(User::getName)
.sorted()
.collect(Collectors.toList());
// ✅ Primitive streams avoid boxing
int sum = numbers.stream()
.mapToInt(Integer::intValue)
.sum();
// 🔴 Parallel on small collection - overhead > benefit
smallList.parallelStream().map(...); // < 10K items
// 🔴 Parallel with shared mutable state
List<String> results = new ArrayList<>();
items.parallelStream()
.forEach(results::add); // Race condition!
// ✅ Parallel for CPU-intensive + large collections
List<Result> results = largeDataset.parallelStream() // > 10K items
.map(this::expensiveCpuComputation)
.collect(Collectors.toList());
Boxing creates objects on heap, adds GC pressure. JVM caches small values (-128 to 127) but not larger ones.
> Future: Project Valhalla will improve this significantly.
// 🔴 Boxing in tight loop - creates millions of objects
Long sum = 0L;
for (int i = 0; i < 1_000_000; i++) {
sum += i; // Unbox, add, box
}
// ✅ Primitive
long sum = 0L;
for (int i = 0; i < 1_000_000; i++) {
sum += i;
}
// 🟡 Boxing overhead
int sum = list.stream()
.reduce(0, Integer::sum);
// ✅ Primitive stream
int sum = list.stream()
.mapToInt(Integer::intValue)
.sum();
This advice is not outdated - Pattern.compile is expensive.
// 🔴 Compiles pattern every iteration
for (String input : inputs) {
if (input.matches("\\d{3}-\\d{4}")) { // Compiles regex!
process(input);
}
}
// ✅ Pre-compile
private static final Pattern PHONE = Pattern.compile("\\d{3}-\\d{4}");
for (String input : inputs) {
if (PHONE.matcher(input).matches()) {
process(input);
}
}
// 🟢 Low severity - but free optimization if size known
List<User> users = new ArrayList<>(expectedSize);
Map<String, User> map = new HashMap<>(expectedSize * 4 / 3 + 1);
// 🟡 O(n) lookup in loop
List<String> allowed = getAllowed();
for (Request r : requests) {
if (allowed.contains(r.getId())) { } // O(n) each time
}
// ✅ O(1) lookup
Set<String> allowed = new HashSet<>(getAllowed());
for (Request r : requests) {
if (allowed.contains(r.getId())) { } // O(1)
}
// 🔴 Memory risk - could grow unbounded
@GetMapping("/users")
public List<User> getAllUsers() {
return userRepository.findAll(); // Millions of rows?
}
// ✅ Pagination
@GetMapping("/users")
public Page<User> getUsers(Pageable pageable) {
return userRepository.findAll(pageable);
}
// 🟡 Traditional thread pool for I/O - wastes OS threads
ExecutorService executor = Executors.newFixedThreadPool(100);
for (Request request : requests) {
executor.submit(() -> callExternalApi(request)); // Blocks OS thread
}
// ✅ Virtual threads - millions of concurrent I/O operations
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (Request request : requests) {
executor.submit(() -> callExternalApi(request));
}
}
// ✅ Structured concurrency for parallel I/O
try (StructuredTaskScope.ShutdownOnFailure scope = new StructuredTaskScope.ShutdownOnFailure()) {
Future<User> user = scope.fork(() -> fetchUser(id));
Future<Orders> orders = scope.fork(() -> fetchOrders(id));
scope.join();
scope.throwIfFailed();
return new UserProfile(user.resultNow(), orders.resultNow());
}
# Find regex in loops (potential compile overhead)
grep -rn "\.matches(\|\.split(" --include="*.java"
# Find potential boxing (Long/Integer as variables)
grep -rn "Long\s\|Integer\s\|Double\s" --include="*.java" | grep "= 0\|+="
# Find ArrayList without capacity
grep -rn "new ArrayList<>()" --include="*.java"
# Find findAll without pagination
grep -rn "findAll()" --include="*.java"
Efficient database search tool for bioRxiv preprint server. Use this skill when searching for life sciences preprints by keywords, authors, date ranges, or categories, retrieving paper metadata, downloading PDFs, or conducting literature reviews.
Access BRENDA enzyme database via SOAP API. Retrieve kinetic parameters (Km, kcat), reaction equations, organism data, and substrate-specific enzyme information for biochemical research and metabolic pathway analysis.
Access ClinPGx pharmacogenomics data (successor to PharmGKB). Query gene-drug interactions, CPIC guidelines, allele functions, for precision medicine and genotype-guided dosing decisions.
Query NCBI ClinVar for variant clinical significance. Search by gene/position, interpret pathogenicity classifications, access via E-utilities API or FTP, annotate VCFs, for genomic medicine.
Access COSMIC cancer mutation database. Query somatic mutations, Cancer Gene Census, mutational signatures, gene fusions, for cancer research and precision oncology. Requires authentication.
Query Ensembl genome database REST API for 250+ species. Gene lookups, sequence retrieval, variant analysis, comparative genomics, orthologs, VEP predictions, for genomic research.
Query openFDA API for drugs, devices, adverse events, recalls, regulatory submissions (510k, PMA), substance identification (UNII), for FDA regulatory data analysis and safety research.
Query NCBI Gene via E-utilities/Datasets API. Search by symbol/ID, retrieve gene info (RefSeqs, GO, locations, phenotypes), batch lookups, for gene annotation and functional analysis.
Take decebals/performance-smell-detection from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.