-
Epic
-
Resolution: Unresolved
-
High
-
None
-
None
-
None
-
None
-
Operating System: All
Platform: All
-
Parser Performance
Similar to earlier YANGTOOLS-629 I've done some profiling of SingleFeatureTest (in netvirt/vpnservice/features) using https://git.opendaylight.org/gerrit/#/c/41349/, and obtained results such as the attached Java Mission Control Flight Recorder JFR ...
mvn runs for a total time of 22 min. and produces 5x JFRs, because SingleFeatureTest starts 5 separate Karaf JVMs. Of these, 1 of 5 is not that interesting as very short, and the other 4 all run for 2-3 minutes and all 4 very show very similar hotspots; I've attached one of them as *.jfr.zip: We spend total 70% (= 30% java.util, 20% com.google.common.collect, 20% org.opendaylight.yangtools.yang.parser.stmt.reactor) around kind of call stack shown in attached *stacks.txt.
There is probably another separate, and bigger issue elsewhere - because this (above) only accounts for ~ 4*3' =~ 12 min - so there is 10' spent somewhere else, in the SingleFeatureTest (not forked Karaf) JVM doing.. I'm not sure what; will try to find out more. Independently fixing this performance bottleneck in YANG Tools already would certainly still be beneficial anyway.
Robert & Peter, I'm hoping you can work similar magic here like you had in YANGTOOLS-629?
- is blocked by
-
YANGTOOLS-1066 SchemaPath identification of SchemaNodes is costly and useless
- Resolved
- relates to
-
YANGTOOLS-1348 Remove Binding-only constructs from YANG parser
- Confirmed
-
YANGTOOLS-855 yang-maven-plugin scans dependencies twice
- Resolved