https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-652 yangtools <p>Similar to earlier <a href="https://jira.opendaylight.org/browse/YANGTOOLS-629" title="Performance optimization potential in yang loading? Profiling SingleFeatureTest shows Hot Methods in e.g. StmtContextUtils &amp; StatementDefinitionContext" class="issue-link" data-issue-key="YANGTOOLS-629"><del>YANGTOOLS-629</del></a> I've done some profiling of SingleFeatureTest (in netvirt/vpnservice/features) using <a href="https://git.opendaylight.org/gerrit/#/c/41349/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/41349/</a>, and obtained results such as the attached Java Mission Control Flight Recorder JFR ... </p> <p>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.</p> <p>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.</p> <p>Robert &amp; Peter, I'm hoping you can work similar magic here like you had in <a href="https://jira.opendaylight.org/browse/YANGTOOLS-629" title="Performance optimization potential in yang loading? Profiling SingleFeatureTest shows Hot Methods in e.g. StmtContextUtils &amp; StatementDefinitionContext" class="issue-link" data-issue-key="YANGTOOLS-629"><del>YANGTOOLS-629</del></a>? <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-652

Improve YANG parser performance and footprint

Epic High Confirmed Unresolved Unassigned Michael Vorburger Wed, 24 Aug 2016 11:41:06 +0000 Thu, 6 Apr 2023 16:22:46 +0000 0 4 <p>Attachment SingleFeatureTest-Karaf-JavaFlightRecorder1118899505783732969.jfr.zip has been added with description: JMC</p> <p>Attachment bug6522_stacks.txt has been added with description: Hot Methods Stack Traces</p> <p>As I mentioned in our email conversation, we will have to look at it closer and try to find out the root cause. So we will see what we can do in this matter.</p> <p>Thanks.<br/> Peter</p> <p>&gt; another separate, and bigger issue elsewhere - (...) there is 10' spent somewhere else in the<br/> &gt; SingleFeatureTest (not forked Karaf) JVM doing.. I'm not sure what; will try to find out more. </p> <p>FTR: I'm not able to reliably reproduce and profile this part anymore - huh?! I'm, now, consistently seeing mvn in netvirt/vpnservice/features at Total time: 10:15 min, which is roughly in line with the finding above for YANG parsing. I will stop chasing another angle, and just profile SingleFeatureTest again from scratch once this issue here will have been addressed.</p> <p>Linking <a href="https://jira.opendaylight.org/browse/CONTROLLER-1480" title="Remove XSQL" class="issue-link" data-issue-key="CONTROLLER-1480"><del>CONTROLLER-1480</del></a> (just pointed out by Stephen in private emails), seems related..</p> <p>Similar symptoms were described here: <a href="https://bugs.opendaylight.org/show_bug.cgi?id=4462" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=4462</a></p> <p>The codebase has shifted significantly since August, so I would suggest collecting a new set of data from current master.</p> <p>One problem identified, though, is SubstatementContext.isConfiguration(), this patch: <a href="https://git.opendaylight.org/gerrit/49567" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/49567</a> should speed it up significantly.</p> <p>So the heap/performance profile for Junos 19.3  with yangtools-4.0.4 looks like this:</p> <p><span class="image-wrap" style=""><a id="15512_thumb" href="https://jira.opendaylight.org/secure/attachment/15512/15512_yt692-heap.png" title="yt692-heap.png" file-preview-type="image" file-preview-id="15512" file-preview-title="yt692-heap.png"><img src="https://jira.opendaylight.org/secure/thumbnail/15512/_thumb_15512.png" height="112" width="196" style="border: 0px solid black" role="presentation"/></a></span></p> <p><span class="image-wrap" style=""><a id="15513_thumb" href="https://jira.opendaylight.org/secure/attachment/15513/15513_yt692-retained.png" title="yt692-retained.png" file-preview-type="image" file-preview-id="15513" file-preview-title="yt692-retained.png"><img src="https://jira.opendaylight.org/secure/thumbnail/15513/_thumb_15513.png" style="border: 0px solid black" role="presentation"/></a></span></p> <p>which shows that:</p> <ol> <li>we processed the models in ~46 seconds</li> <li>peak memory usage was 2.7GiB</li> <li>final SchemaContext was ~1GiB</li> </ol> <p>The primary cause of memory usage (and also CPU usage) is <a href="https://jira.opendaylight.org/browse/YANGTOOLS-694" title="Eliminate duplicate DescriptionEffectiveStatementImpl objects" class="issue-link" data-issue-key="YANGTOOLS-694"><del>YANGTOOLS-694</del></a>, which creates a lot of contexts during 'uses' propagation (~1.7GiB).</p> <p>While the SchemaContext size can also be blamed on that issue, it highlights the fact that individual effective statement objects are larger that they need to be:</p> <p><span class="image-wrap" style=""><a id="15516_thumb" href="https://jira.opendaylight.org/secure/attachment/15516/15516_yt-692-desc-impl.png" title="yt-692-desc-impl.png" file-preview-type="image" file-preview-id="15516" file-preview-title="yt-692-desc-impl.png"><img src="https://jira.opendaylight.org/secure/thumbnail/15516/_thumb_15516.png" style="border: 0px solid black" role="presentation"/></a></span></p> <p>in this case there are known invariants:</p> <ul> <li>description is always declared</li> <li>it typically does not have substatements (but it could have extensions)</li> <li>its argument matches the declared statement</li> </ul> <p>Hence there is room for improvement with regard to object layout, possibly with specializations.</p> <p> </p> <p>With current yangtools-8.0.0-SNAPSHOT the performance looks much better:</p> <p><span class="image-wrap" style=""><a id="16503_thumb" href="https://jira.opendaylight.org/secure/attachment/16503/16503_junos_yt800_perf.png" title="junos_yt800_perf.png" file-preview-type="image" file-preview-id="16503" file-preview-title="junos_yt800_perf.png"><img src="https://jira.opendaylight.org/secure/thumbnail/16503/_thumb_16503.png" style="border: 0px solid black" role="presentation"/></a></span></p> <p>Heap composition is also much saner, with SchemaPath objects gone and only about 10M objects.<br/> <span class="image-wrap" style=""><a id="16502_thumb" href="https://jira.opendaylight.org/secure/attachment/16502/16502_junos_yt800_heap.png" title="junos_yt800_heap.png" file-preview-type="image" file-preview-id="16502" file-preview-title="junos_yt800_heap.png"><img src="https://jira.opendaylight.org/secure/thumbnail/16502/_thumb_16502.png" height="600" width="1101" style="border: 0px solid black" role="presentation"/></a></span></p> <p>With <a href="https://jira.opendaylight.org/browse/YANGTOOLS-1067" title="Use flyweight EffectiveStatement implementations" class="issue-link" data-issue-key="YANGTOOLS-1067"><del>YANGTOOLS-1067</del></a> and a few other yangtools-8 deliverables we are down to ~3.5M objects.</p> <p><span class="image-wrap" style=""><img src="https://jira.opendaylight.org/secure/attachment/17102/17102_image-2021-12-06-13-00-49-525.png" height="786" width="1438" style="border: 0px solid black" /></span></p> Blocks YANGTOOLS-1066 Relates YANGTOOLS-1348 YANGTOOLS-855 Development Epic Name Parser Performance External issue ID 6522 External issue URL Issue Type Rank 0|i028jr: