Optimizing performance of long running enhancers

[AndreasIgel]

Long running enhancers should be recognized and afterwards optimized.

[AndreasIgel]

Performance Analysis Summary

JIT Warm-up Hypothesis — Confirmed

Experiment: Renamed Abstractor (first alphabetically, ~625ms avg) to ZzzAbstractor (last) and Zoo (last, ~37ms avg) to AaaZoo (first). Ran 10 performance measurement runs with 1077 classes each.

Class	Position	Before	After	Change
Abstractor → ZzzAbstractor	First → Last	625ms	63ms	-90%
Zoo → AaaZoo	Last → First	37ms	807ms	+2078%

The first ~20-30 classes processed pay JIT compilation and class-loading costs for Roaster, the Eclipse formatter, and all generator/enhancer code paths. Once hotspots are compiled, later classes run at steady-state speed (~30-50ms).

Phase Breakdown (10-run averages)

Phase	Time	Share
Code Generation (Roaster)	47.4s	93%
Builder Definition Extraction	0.8s	1.6%
Configuration Resolution	0.1s	0.2%
DTO Mapping	0.03s	0.06%

Code Generation Sub-Phases

Sub-phase	Share of Code Gen
Formatting (Eclipse formatter via Roaster.format())	~40%
String Generation (toUnformattedString())	~31%
Element Building (Roaster AST construction)	~25%
File Writing	~4%

Enhancer Timings

All enhancers combined account for ~75ms across 1077 classes — negligible compared to the 47.4s spent in code generation.

Enhancer	Total (10-run avg)	Per class
CoreMethodsEnhancer	34.5ms	0.032ms
ConstructorEnhancer	14.3ms	0.013ms
ClassJavaDocEnhancer	14.0ms	0.013ms
WithInterfaceEnhancer	7.4ms	0.007ms
All others	~10ms	<0.01ms

Attempted Optimization: CoreMethodsEnhancer Single-Pass Refactor

Refactored CoreMethodsEnhancer:79:0-330:1 to iterate fields once instead of 5 times using a FieldCodeFragments holder to collect code fragments in a single pass.

Result: The refactor made the enhancer 67% slower (34.5ms → 57.6ms) due to the overhead of allocating 5 StringBuilder objects per class. The absolute cost remains negligible (57ms vs 47,400ms for code generation), but the change was reverted since it provided no benefit.

Conclusion

The performance bottleneck is not in the enhancers or field iteration logic. 93% of processing time is spent in Roaster's code generation — specifically Eclipse code formatting (~40%) and string serialization (~31%).

Closing this issue as the analysis is complete and the root cause (Roaster code generation + JIT warm-up) has been identified. No code changes are warranted at this time.