Performance review

[BalusC]

Mojarra performance is poor when compared to MyFaces. Perform performance review and improve where possible.

[BalusC]

GlassFish 8.0.3-SNAPSHOT

Mojarra 4.1.10-SNAPSHOT vs baseline 4.1.9, same benchmark WAR, same server, JDK 21, -Dperf.warmup=50 -Dperf.runs=1000, runs back-to-back to minimize drift.

GlassFish build note: this 8.0.3-SNAPSHOT includes the container-side CDI fix from eclipse-ee4j/glassfish#26046, which caches isInterceptor to skip the isValidAnnotation annotation-hierarchy walk on the CDI injection path (previously ~50% of http-listener CPU on views heavy with managed @FacesConverter/@FacesValidator). Both the 4.1.9 and 4.1.10-SNAPSHOT runs use the same patched GlassFish, so that fix is held constant — the deltas below isolate the Mojarra change, not the GlassFish one.

Wall clock and totals

	4.1.9	4.1.10	Δ	Δ%
Wall clock	258.3 s	230.8 s	-27.5 s	-10.6 %
TOTAL avg µs RESTORE_VIEW	472	411	-61	-12.9 %
TOTAL avg µs APPLY_REQUEST_VALUES	546	491	-55	-10.1 %
TOTAL avg µs PROCESS_VALIDATIONS	3,199	2,925	-274	-8.6 %
TOTAL avg µs UPDATE_MODEL_VALUES	619	581	-38	-6.1 %
TOTAL avg µs INVOKE_APPLICATION	31	31	+0	noise
TOTAL avg µs RENDER_RESPONSE	8,107	7,040	-1,067	-13.2 %

Most-improved phase × scenario combinations

scenario	phase	4.1.9 (µs)	4.1.10 (µs)	Δ%
index	RESTORE_VIEW	69	41	-40.6 %
table-readonly-heavy	RESTORE_VIEW	51	35	-31.4 %
index	RENDER_RESPONSE	533	394	-26.1 %
viewparam-get	RESTORE_VIEW	225	171	-24.0 %
table-inputs	RESTORE_VIEW	692	549	-20.7 %
repeat-readonly-heavy	RESTORE_VIEW	51	41	-19.6 %
table-inputs	APPLY_REQUEST_VALUES	663	537	-19.0 %
viewparam-get	RENDER_RESPONSE	315	260	-17.5 %
table-readonly	RENDER_RESPONSE	7,120	5,885	-17.3 %
table-inputs	RENDER_RESPONSE	3,753	3,130	-16.6 %
repeat-inputs	RENDER_RESPONSE	3,136	2,617	-16.5 %
table-inputs	PROCESS_VALIDATIONS	3,715	3,108	-16.3 %
table-readonly-heavy	RENDER_RESPONSE	46,313	38,980	-15.8 %
form-inputs-ajax	RESTORE_VIEW	583	492	-15.6 %
repeat-inputs-heavy	RENDER_RESPONSE	9,970	8,554	-14.2 %

_{Top 15 by Δ%; phase×scenario combos with baseline avg < 50 µs omitted as noise-bound. Negative Δ% = faster on 4.1.10-SNAPSHOT.}

[BalusC]

WildFly 40.0.0.Final

Mojarra 4.1.10-SNAPSHOT vs baseline 4.1.9, same benchmark WAR, same server, JDK 21, -Dperf.warmup=50 -Dperf.runs=1000, runs back-to-back to minimize drift.

Wall clock and totals

	4.1.9	4.1.10	Δ	Δ%
Wall clock	228.8 s	206.5 s	-22.3 s	-9.8 %
TOTAL avg µs RESTORE_VIEW	414	387	-27	-6.5 %
TOTAL avg µs APPLY_REQUEST_VALUES	397	370	-27	-6.8 %
TOTAL avg µs PROCESS_VALIDATIONS	2,509	2,425	-84	-3.3 %
TOTAL avg µs UPDATE_MODEL_VALUES	502	484	-18	-3.6 %
TOTAL avg µs INVOKE_APPLICATION	25	25	+0	noise
TOTAL avg µs RENDER_RESPONSE	8,717	7,552	-1,165	-13.4 %

Most-improved phase × scenario combinations

scenario	phase	4.1.9 (µs)	4.1.10 (µs)	Δ%
viewparam-get	RESTORE_VIEW	178	120	-32.6 %
index	RESTORE_VIEW	62	42	-32.3 %
viewparam-get	PROCESS_VALIDATIONS	95	77	-18.9 %
table-readonly	RENDER_RESPONSE	6,775	5,610	-17.2 %
index	RENDER_RESPONSE	467	390	-16.5 %
table-readonly-heavy	RENDER_RESPONSE	55,836	46,739	-16.3 %
repeat-readonly-heavy	RENDER_RESPONSE	45,395	38,499	-15.2 %
table-inputs	APPLY_REQUEST_VALUES	468	415	-11.3 %
composite-readonly	RENDER_RESPONSE	6,976	6,190	-11.3 %
table-inputs	UPDATE_MODEL_VALUES	580	519	-10.5 %
table-inputs-ajax	RESTORE_VIEW	566	509	-10.1 %
repeat-inputs-ajax	RESTORE_VIEW	500	450	-10.0 %
repeat-readonly	RENDER_RESPONSE	5,043	4,562	-9.5 %
repeat-inputs	RESTORE_VIEW	460	417	-9.3 %
form-inputs	RESTORE_VIEW	547	496	-9.3 %

_{Top 15 by Δ%; phase×scenario combos with baseline avg < 50 µs omitted as noise-bound. Negative Δ% = faster on 4.1.10-SNAPSHOT.}

[BalusC]

TomEE Plume 10.1.5

Mojarra 4.1.10-SNAPSHOT vs baseline 4.1.9, same benchmark WAR, same server, JDK 21, -Dperf.warmup=50 -Dperf.runs=1000, runs back-to-back to minimize drift.

TomEE EE 11 shim: Plume 10.1.5 is a Jakarta EE 10 server; Mojarra 4.1.x is Faces 4.1 / Jakarta EE 11. Because there is no EE 11 TomEE release yet (TomEE 11 is not yet available — 10.1.5 is the current stable, and it is EE 10), the EE 11 API classes Mojarra references were overlaid into Plume's lib/ — jakarta.el-api 6.0.1 (OptionalELResolver), jakarta.enterprise.cdi-el-api 4.1.0 (ELAwareBeanManager), jakarta.enterprise.cdi-api 4.1.0. The same shim is applied to both 4.1.9 and 4.1.10-SNAPSHOT, so the delta stays a fair Mojarra-vs-Mojarra comparison on this (deliberately doctored) stack.

Why the wins dwarf GlassFish/WildFly: they are concentrated on input-bearing views (postback RESTORE_VIEW + RENDER_RESPONSE); output-only/readonly renders improve only ~9% here, same as elsewhere. 4.1.9 had a render/state cost that scales with write volume and that Tomcat's output layer amplifies heavily; 4.1.10's response-writer (#5755) and component-tree (#5754) work removes it.

Run twice to reconfirm: because this −56% wall-clock swing was so much larger than the ~9–10% seen on GlassFish/WildFly, the full baseline + snapshot pair was executed twice, independently (the second time with the host otherwise idle). Both agree closely:

run	4.1.9	4.1.10	Δ%
run 1	531.5 s	224.1 s	−57.8 %
run 2 (idle)	508.5 s	220.5 s	−56.6 %

The tables below use run 2. Within each run, baseline min_us ≈ avg_us (steady-state, not GC/warmup noise) — e.g. table-inputs-heavy RENDER min 82,240 → 7,418 µs — so the effect is a genuine per-request cost, not tail-latency outliers.

The two small regressions (PROCESS_VALIDATIONS +10.5 %, UPDATE_MODEL_VALUES +13.0 %) are the same signature — and most likely the same cause — as the GlassFish isValidAnnotation-cache result in #5756 (comment): a JIT profile shift. Once the dominant RESTORE_VIEW/RENDER_RESPONSE hotspot is removed, the compiler's inlining/tiering for the now-relatively-hotter remaining phases changes and nudges those small CPU-bound phases up. The absolute cost is tiny — +270 µs PROCESS_VALIDATIONS and +78 µs UPDATE_MODEL_VALUES against −14,544 µs on RENDER_RESPONSE — so it does not dent the −56.6 % wall clock.

Wall clock and totals

	4.1.9	4.1.10	Δ	Δ%
Wall clock	508.5 s	220.5 s	-288.0 s	-56.6 %
TOTAL avg µs RESTORE_VIEW	2,155	472	-1,683	-78.1 %
TOTAL avg µs APPLY_REQUEST_VALUES	497	505	+8	+1.6 %
TOTAL avg µs PROCESS_VALIDATIONS	2,574	2,844	+270	+10.5 %
TOTAL avg µs UPDATE_MODEL_VALUES	598	676	+78	+13.0 %
TOTAL avg µs INVOKE_APPLICATION	43	42	-1	-2.3 %
TOTAL avg µs RENDER_RESPONSE	22,248	7,704	-14,544	-65.4 %

Most-improved phase × scenario combinations

scenario	phase	4.1.9 (µs)	4.1.10 (µs)	Δ%
repeat-inputs-heavy	RENDER_RESPONSE	88,095	8,492	-90.4 %
table-inputs-heavy	RENDER_RESPONSE	87,664	8,683	-90.1 %
viewparam-get	RESTORE_VIEW	1,247	146	-88.3 %
repeat-nested	RENDER_RESPONSE	17,296	2,097	-87.9 %
table-inputs	RENDER_RESPONSE	24,395	3,036	-87.6 %
form-inputs	RESTORE_VIEW	4,619	575	-87.6 %
repeat-inputs	RENDER_RESPONSE	20,128	2,757	-86.3 %
form-inputs-ajax	RESTORE_VIEW	3,584	499	-86.1 %
composite-nested	RENDER_RESPONSE	24,417	3,763	-84.6 %
composite-inputs	RENDER_RESPONSE	19,701	3,235	-83.6 %
table-inputs	RESTORE_VIEW	3,569	642	-82.0 %
repeat-inputs-ajax	RESTORE_VIEW	2,938	568	-80.7 %
repeat-inputs	RESTORE_VIEW	2,956	591	-80.0 %
table-inputs-ajax	RESTORE_VIEW	2,946	618	-79.0 %
composite-inputs	RESTORE_VIEW	2,896	691	-76.1 %

_{Top 15 by Δ%; phase×scenario combos with baseline avg < 50 µs omitted as noise-bound. Negative Δ% = faster on 4.1.10-SNAPSHOT.}

[BalusC]

Cross-server aftermath — same Mojarra 4.1.10-SNAPSHOT on three containers

All three runs use the identical Mojarra 4.1.10-SNAPSHOT jakarta.faces.jar, the same benchmark WAR, the same JDK 21, and -Dperf.warmup=50 -Dperf.runs=1000. Because Mojarra is held constant, the spread below is container-attributable — Grizzly/Weld vs Undertow/Weld vs Tomcat/OpenWebBeans, plus each server's CDI and EL resolution cost on the Faces lifecycle path.

TomEE caveat: Plume 10.1.5 is Jakarta EE 10 and was shimmed up to EE 11 (overlaid jakarta.el-api 6.0.1 + CDI 4.1 API jars) to run Faces 4.1 — a doctored stack, so read its absolute numbers with that in mind. GlassFish caveat: this 8.0.3-SNAPSHOT includes the CDI-injection fix eclipse-ee4j/glassfish#26046.

Wall clock (timed loop, all 18 scenarios × 1000 runs)

server	wall clock	relative
WildFly 40.0.0.Final	206.5 s	1.00× (fastest)
TomEE Plume 10.1.5	220.5 s	1.07× slower
GlassFish 8.0.3-SNAPSHOT	230.8 s	1.12× slower

Per-phase server-side time — TOTAL avg µs across all scenarios

phase	GlassFish 8.0.3-SNAPSHOT	WildFly 40.0.0.Final	TomEE Plume 10.1.5
RESTORE_VIEW	411	387	472
APPLY_REQUEST_VALUES	491	370	505
PROCESS_VALIDATIONS	2,925	2,425	2,844
UPDATE_MODEL_VALUES	581	484	676
INVOKE_APPLICATION	31	25	42
RENDER_RESPONSE	7,040	7,552	7,704

_{bold = fastest server for that row. These are server-side Faces-lifecycle microbench timings (one run each, single host), not a general server-throughput benchmark — read them as "how cheap is the Faces request pipeline on this stack", not "server X is N× faster overall".}

[pizzi80]

this is the best review and PR(s) ever made in the JSF history

[kito99]

This is pretty awesome! I'd love to see it on other environments, like Liberty, Quarkus, Helidon, Fijutsu, Spring Boot, etc. :-). But that's more out of curiosity than necessity....

[melloware]

This is awesome!

[BalusC]

Yes :)

FYI: I wanted to run MyFaces numbers on same servers as well, but MyFaces 4.1.3 keeps OOM GC-thrashing on this benchmark WAR .. Even with 12GB while Mojarra runs comfortably with default 512M .. Although the preliminary numbers suggest MyFaces is still ~5% faster .. Stay tuned ..

[melloware]

weird i would not expect MyFaces to run OOM but let us know what you find out it could be a MyFaces bug!