[roozbehp]

This is mathematically equivalent, and makes list-unicodeset.jsp result for [:L:] 39x faster, changing from 16s to 0.4s on my local benchmark. It also vastly reduces temporary memory allocations.

• Approver: Feel free to merge on my behalf
  • rebase & merge one or more commits
  • squash & merge multiple commits into one

[roozbehp]

@eggrobin, here's an analysis of why isTrivial() was slowing things down. The call sequence is/was:

1. list-unicodeset.jsp called UnicodeJsp.showSet().
2. That called UnicodeUtilities.showSetMain(), then UnicodeUtilities.showSet().
3. Inside its character loop, showSet() resolved the four properties in Resolve some properties outside the loop in UnicodeUtilities.java #1606 for every character.
4. Each XPropertyFactory.getProperty(alias) called VersionedProperty.forJSPs(...).set(alias).
5. VersionedProperty.set() called property.isTrivial() twice for these properties.

The two calls came from these conditions:

if ((property == null && TOOL_ONLY_PROPERTIES.contains(xPropertyName))
        || (property != null && property.isTrivial() && allowRetroactive)) {
    ...
}
if (property == null || property.isTrivial()) {
    ...
}

The first condition evaluated isTrivial() even when allowRetroactive was false (fix in #1606). The second condition evaluated it again.

For the benchmark’s 158,172 letters, the grouping loop alone therefore caused:

• 632,688 property resolutions: four per character.
• 1,265,376 isTrivial() calls: two per resolution.

Fetching character names added another path: CodePointShower.showCodePoint() called showString(), which called UnicodeUtilities.getName(), which resolved "Name" through that same factory. The benchmark’s raw Name map contained about 52,000 ranges, making those repeated checks particularly expensive.