Severe performance regression in JavaPackage
#1100
Comments
odrotbohm
added
in: core
odrotbohm
added a commit
that referenced
this issue
Mar 4, 2025
The fix for GH-1041 introduced a performance regression as the calculation of the sub-packages escaped the SingletonSupplier and thus is now included in every hashCode() calculation. Took the chance to significantly revamp the sub-package calculation for nested packages. In other words, the entire sub-package arrangement for a package is calculated once with pre-computed intermediaries held instead of re-computing them per sub-package.
odrotbohm
added a commit
that referenced
this issue
Mar 7, 2025
We now resort to a simple iteration over the types within a Classes arrangement to detect all classes residing in certain packages. This is primarily used during the JavaPackage data structure construction as it's called for every sub-package of a package originally created from a Classes instance. The new simplified algorithm avoids set up of DescribedPredicate instances to eventually only perform simple package name checks.
odrotbohm
added a commit
that referenced
this issue
Mar 7, 2025
We now resort to a simple iteration over the types within a Classes arrangement to detect all classes residing in certain packages. This is primarily used during the JavaPackage data structure construction as it's called for every sub-package of a package originally created from a Classes instance. The new simplified algorithm avoids set up of DescribedPredicate instances to eventually only perform simple package name checks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Back-port of GH-1098.
The text was updated successfully, but these errors were encountered: