Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reduce cpu usage for proxy creation #687

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Reduce cpu usage for proxy creation #687

wants to merge 4 commits into from

Commits on Nov 2, 2024

  1. Make tests more platform independent 

    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.
    @DaScheid
    DaScheid committed Nov 2, 2024
    Configuration menu
    Copy the full SHA
    bd4a492 View commit details
    Browse the repository at this point in the history

  2. Reuse JAXBContext 

    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.
    @DaScheid
    DaScheid committed Nov 2, 2024
    Configuration menu
    Copy the full SHA
    b1d152c View commit details
    Browse the repository at this point in the history

  3. Reduce inits of MetroConfigLoader 

    Creating a MetroConfigLoader requires frequent class- and resource-loading, so re-use factories when applicable
    @DaScheid
    DaScheid committed Nov 2, 2024
    Configuration menu
    Copy the full SHA
    b3537a6 View commit details
    Browse the repository at this point in the history

  4. Cache ServiceLoader-calls without result 

    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
    DaScheid committed Nov 2, 2024
    Configuration menu
    Copy the full SHA
    981109e View commit details
    Browse the repository at this point in the history