Uploaded image for project: 'yangtools'
  1. yangtools
  2. YANGTOOLS-629

Performance optimization potential in yang loading? Profiling SingleFeatureTest shows Hot Methods in e.g. StmtContextUtils & StatementDefinitionContext

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • None
    • None
    • None
    • None
    • Operating System: All
      Platform: All

    • 6158

      I was curious today why that SingleFeatureTest was taking so long (e.g. approx. 15' on netvirt/vpnservice/features currently), and did some profiling using (Oracle, not OpenJDK) Java Mission Control of a local Maven build. I'll attach the zipped *.jfr file if anyone else wants to have a look.

      If I'm interpreting things correctly, which I may not, then a (to me) surprising fraction of the time spent in SingleFeatureTest, something like 20% (maybe I'm adding up things that are showing twice the same), is spent not in Karaf code loading features and all, nor in actual functional bundle initialization stuff (like netvirt or so) but in yangtools related stuff to load *.yang files. If this is just perfectly normal and to be expected, in the SingleFeatureTest use case, then please feel free to close this as WONTFIX.

      Just wondering if there isn't any Performance optimization potential in yang loading ... I've played with 1-2 things myself locally, related to more efficient collection use (I'll put in a Gerrit for that). My change does get the related code out of the Hot Methods in JMC, but overall still seems to have very little impact on the ca. 15' SingleFeatureTest of netvirt/vpnservice/features, unfortunately.

      After that change of mine, the Hot Methods in JMC seems to say that ca. 10% of the total time is in java.util.Collections$UnmodifiableCollection$1.hasNext() related to org.opendaylight.yangtools.yang.parser.spi.meta.StmtContextUtils.findFirstEffectiveSubstatement, and another 10% (which may be the same; I'm not 100% sure how to interpret) related to org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementDefinitionContext getPublicView() and org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase getPublicDefinition(), which doesn't really make any sense to me, as upon a closer look the call chain just seems to be a bunch of getters calling through, so I'm not sure what to make of that.

      Without fully understanding the internals, I'm wondering it it may be feasible to apply some caching somewhere (related to what jumps out as Hot Methods in JMC) ?

            pkajsa Peter Kajsa
            vorburger Michael Vorburger
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: