[8Keep]

Bulk-copy LightList updates and longer removal shifts. Use stable insertion sort up to 64 lights, with merge sort for larger lists and NaN distances.

Clear sorting scratch after every use, including exceptions, so removed lights are not retained. Compute distances before using scratch to handle nested world-light sorts. Filtered updates reserve space for accepted lights and use the parent's size after filter callbacks.

Measurements on this machine, master 6961525e → this PR:

Operation	Before → after
Update, 8 local + 8 parent lights, unfiltered	20.6 → 12.8 ns
Update, 257 + 257, unfiltered	331 → 95.6 ns
Update, 257 + 257, reject quarter of locals	407 → 256 ns
Re-sort 256 point lights after owner movement	11.83 → 11.75 µs
Same re-sort, retained capacity 1024×	55.65 → 12.22 µs

All eight update cases improve over master. Ordinary-capacity re-sort intervals include both gains and regressions; retained-capacity stress cases improve. These re-sort measurements do not include clear/refill.

There are costs versus the previous PR: 256-light re-sorts execute about 5–7% more instructions with immediate scratch cleanup. The 257-light quarter-rejection update uses 13% more instructions while reducing reserved capacity from 1024 to 512 slots. Their timing differences remain inconclusive.

i7-11800H, Fedora 44, Temurin 25.0.4, JMH 1.37; CPU 2, one thread, 256 MiB heap. Six independent JVM groups in all six execution orders, 5×400 ms warmup and 6×300 ms measurement. Other work was running; dynamic clocks and contention limit timing claims. No FPS claim.

Core suite: 1,185 tests, zero failures, one skipped. Regression coverage includes shrinking/removing sorted lists, exceptions, nested sorts, NaNs, and parent-mutating filters. Both fixed-input render scenes match the published PR pixel for pixel.

[gemini-code-assist]

Code Review

This pull request introduces the Java Microbenchmark Harness (JMH) to the project, adding a dedicated benchmark source set and several performance tests for bounding volumes, light lists, and geometry lists. In LightList, several methods including remove, clear, sort, and update were optimized using System.arraycopy and Arrays.fill to improve efficiency. Feedback suggests removing the distToOwner array and its associated logic in LightList, as it is currently dead code and not correctly synchronized during element removal.

[riccardobl]

Benchmarks should be moved into their own jme3-benchmark module, so that we don't have to deal with them in the normal codebase.

Other than that and the distToOwner comment by gemini, everything looks good.

[8Keep]

Should be solid now

[8Keep]

@riccardobl could you take another look?

[riccardobl]

@copilot resolve the merge conflicts in this pull request

[8Keep]

Rebased and fixed some things and whatnot

[jaime-jmebot]

• The benchmark code is now isolated in its own jme3-benchmark module, addressing the requested separation.
• The LightList changes and added tests look sound, including the retained-capacity and NaN sorting cases.
• No further issues found in this review.

[riccardobl]

this can leave references to unused lights at the end of tlist when it shrinks, preventing them from being garbage collected.