Performance review of view build time

[BalusC]

#5753 closed the biggest gap with MyFaces. But the remaining gap is in the view build time. The latest bench numbers still show relatively big diffs in Restore View phase of *-build and *-get scenarios, although small in absolute time. This gap needs to be reviewed and closed.

[pizzi80]

I merged 4.1 HEAD into my fork (let's call it 4.2.11) and used the new perf
suite to compare it against the official 4.1.11.

Caveat: my fork tracks 4.1 HEAD, which is ahead of the 4.1.11 tag,
so it includes also the following PR:

• Fix #5878: match resource exclusions with endsWith, not a regex #5879
• Fix #5880: merge attributesThatAreSet delta on restore instead of replacing #5881
• Fix #5792: widen h:panelGroup wrapper gate to any renderable attribute #5882

A note on methodology first, because I ran into some pitfalls with the suite:

• Warmup matters a lot. At warmup=50 I was measuring JIT compilation state
  rather than steady-state behaviour — several scenarios flipped sign entirely
  when I raised it. I settled on warmup=200 runs=2000.
• Run order introduces drift, so I ran A-B-A (fork → official → fork) and
  used the two fork runs as a control: identical bytecode, so any difference
  between them is pure measurement noise.

With that control in place, the deltas sit 3–7× above the noise floor:

Phase	Official 4.1.11	Fork (mean of 2 runs)	Δ	Noise floor
RESTORE_VIEW	201 µs	197.5 µs	+1.8 %	0.6 %
PROCESS_VALIDATIONS	199 µs	196.0 µs	+1.5 %	0.2 %
RENDER_RESPONSE	518 µs	513.5 µs	+0.9 %	0.2 %
Full request	1088 µs	1076.0 µs	+1.1 %	0.4 %

Positive Δ = fork is faster. Per-scenario figures are not reportable — in the
identical-bytecode control they swing by ±10–45 %, so only totals are meaningful.

One limitation worth noting: the perf suite is single-threaded, so it doesn't
capture the dimension where part of this work actually applies. Reduced
allocation shows up as GC pause frequency under concurrent load — and those
pauses are paid by every in-flight request, not just the one that allocated.
Lock contention isn't exercised at all.

I'm not claiming a larger speedup under load; the CPU-side gain is what it is.
But the allocation and contention effects are simply invisible to this harness,
so the 1.1 % is best read as a lower bound on the CPU side rather than as the
whole picture.

The fork contains a fairly large number of changes, roughly in these categories:

• micro-optimisations on hot paths
• reduced object allocation
• reduced lock contention on some paths
• reduced access to shared data structures
• reduced Collections internal resize
• readability cleanups (which also made a few hot paths easier to spot)
• a few potential race conditions in lazily-initialised application-scoped state
• a few potential race conditions in lazily-initialised session-scoped state
• removal of some unreachable null checks
• graceful handling of IllegalStateException when session-scoped state is
  accessed while the session is concurrently invalidated: the accessor now
  returns null (which callers already handle) instead of propagating an
  exception to the user for a condition that is intrinsically racy

Happy to backport any of this upstream as separate, focused PRs if there's
interest — I'd rather split them by category than send one large diff. Let me
know which of these would be most useful and I'll start there.

[BalusC]

As long as behavior is unchanged, microopts are welcome (I guess that excludes the ISE item). One PR is okay as long as each microopt is in a separate reviewable commit. Claude e.g. can quickly do that.

Note: this is not really a "performance review of view build time".

[pizzi80]

The behavior is unchanged ...

I have to figure how to organize the PRs ... probably with the help of Claude
starting from the diff / git log and commit related classes

... I'll try ... at the end of the day it's only java code ...

IllegalStateException is imho bad treaten because Faces is the end product
that have to absorb all the incongrueces and bugs of CDI / Servlet / ServletContainer,
so my idea is that Faces should do as much work as possible to
mitigate bad things of those layers ...

[BalusC]

Change in spec/api/behavior just needs its own new issue in Faces project. Then we'll see if it ends up in 5.0 or 5.1 or later.