Reduce cpu usage for proxy creation #687
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukasj
requested changes
Jun 17, 2024
DaScheid
force-pushed
the
reduce-cpu-usage-for-proxy-creation
branch
from
afdd029 to
ceef811
Compare
|
Updated license agreement, made changes as requested |
Some tests implicitly require a specific line-ending or a locale to be set. Adjusting those to run the test-suites without changing the local dev-setup.
Cache JAXBContext to avoid frequent instantiations of it. The benefit of this caching depend on the use implementation of "jakarta.xml.bind.JAXBContextFactory", e.g. the glassfish-implementation is faster as some others, so the computation-time saved here is lower when using glassfish-impl compared to using a slower implementation.
Creating a MetroConfigLoader requires frequent class- and resource-loading, so re-use factories when applicable
Iterating over the ServiceLoader results in class- and resource-loading, which becomes expensive if done extensively.
A common pattern used (in e.g. "com.sun.xml.ws.api.pipe.TransportTubeFactory::create") is to search first for multiple factory-implementations before falling back to a "default" factory / implementation:
public Type exampleFunc(...) {
for (_ : ServiceFinder.find(FactoryType1.class) { return if FactoryType1-impl found }
for (_ : ServiceFinder.find(FactoryType2.class) { return if FactoryType2-impl found }
return DEFAULT_FACTORY.createType(..);
}
If there are no other implementations present besides the default-fallback-implementation, then each call to a method with this structure starts searching (again) for all non-default implementations - only to not find any implementing classes and finally falling back to the default-implementation.
Invoking such method-structures often, results in multiple unnecessary ServiceLoader-calls, because if the corresponding service-class and classloader are identical to a previous call and for this previous call the classloader was not able to determine the service-implementation, then it still won't be able to find it when retrying the ServiceLoader-call with the same parameters.
DaScheid
force-pushed
the
reduce-cpu-usage-for-proxy-creation
branch
from
ceef811 to
981109e
Compare
|
Rebased onto latest master-branch. PR would be ready for review, @lukasj |
|
I am also affected by this performance problem. The patch shows significant performance improvements (factor 20) for my use case. Is there anything I can contribute to progress this? |
|
@lukasj What can be done to progress this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue #686