glassfish
  1. glassfish
  2. GLASSFISH-19107

[PERF] Large Regression in DomainXml parsing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b55
    • Fix Version/s: 4.0
    • Component/s: hk2
    • Labels:
      None

      Description

      Domain start time has regressed significantly on all platforms since around build 50 (late August). Profiles show that the largest part of the regression comes from org.glassfish.config.support.DomainXml.parseDomainXml – this used to take a less than 100 ms in previous builds and now takes half a second. The size of the domain.xml is larger in later builds, but even if we substitute the earlier domain.xml, parsing still takes half a second, so this seems to be related to the changes that were made for HK2 around the end of August.

        Issue Links

          Activity

          Hide
          Scott Oaks added a comment -

          I have done some additional analysis on the parsing.

          It turns out, as I thought might be the case, that the recursion chain itself is about the same length (actually slightly shorter in GF 4.0), but that the operations in the recursion leaves are longer, which leads to the regression. Specifically, the difference is in DomDocument.buildModel(String s). In 3.1.2 (HK 2.1.14), that would call habitat.getInhabitantByAnnotation(s). On 4.0 (HK 2.2.N), that calls habitat.getBestDescriptor(s) and then Utilities.getInhabitantFromActiveDescriptor.

          Some rudimentary timing with System.nanoTime yields that the average time per call for getInabitantByAnnotation is 550 microseconds, but the average time for the two calls in 4.x is 3.2 milliseconds – a 6x difference. And unfortunately while the difference in absolute terms seems very small, the code path is called about 190 times while parsing the domain.xml, and the net result is the half-second regression.

          Show
          Scott Oaks added a comment - I have done some additional analysis on the parsing. It turns out, as I thought might be the case, that the recursion chain itself is about the same length (actually slightly shorter in GF 4.0), but that the operations in the recursion leaves are longer, which leads to the regression. Specifically, the difference is in DomDocument.buildModel(String s). In 3.1.2 (HK 2.1.14), that would call habitat.getInhabitantByAnnotation(s). On 4.0 (HK 2.2.N), that calls habitat.getBestDescriptor(s) and then Utilities.getInhabitantFromActiveDescriptor. Some rudimentary timing with System.nanoTime yields that the average time per call for getInabitantByAnnotation is 550 microseconds, but the average time for the two calls in 4.x is 3.2 milliseconds – a 6x difference. And unfortunately while the difference in absolute terms seems very small, the code path is called about 190 times while parsing the domain.xml, and the net result is the half-second regression.
          Hide
          jwells added a comment -

          I've checked in a change to DomDocument.buildModel which should fix the performance difference in most cases. This will come into GlassFish after 2.1.39 is accepted by GlassFish (which could take a couple of days).

          Show
          jwells added a comment - I've checked in a change to DomDocument.buildModel which should fix the performance difference in most cases. This will come into GlassFish after 2.1.39 is accepted by GlassFish (which could take a couple of days).
          Hide
          Tom Mueller added a comment -

          John, did the change you check in resolve this problem? If so, please mark this issue as resolved. Otherwise, please resolve the problem.

          Thanks.
          Tom

          Show
          Tom Mueller added a comment - John, did the change you check in resolve this problem? If so, please mark this issue as resolved. Otherwise, please resolve the problem. Thanks. Tom
          Hide
          Scott Oaks added a comment -

          I have just verified that the parseDomainXML performance has returned to 3.1.2 levels.

          Show
          Scott Oaks added a comment - I have just verified that the parseDomainXML performance has returned to 3.1.2 levels.
          Hide
          jwells added a comment -

          Since this regression is back to 3.1 levels I am closing this bug!

          Show
          jwells added a comment - Since this regression is back to 3.1 levels I am closing this bug!

            People

            • Assignee:
              jwells
              Reporter:
              Scott Oaks
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: