[YANGTOOLS-652] Improve YANG parser performance and footprint Created: 24/Aug/16  Updated: 06/Apr/23

Status: Confirmed
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: High
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: Zip Archive SingleFeatureTest-Karaf-JavaFlightRecorder1118899505783732969.jfr.zip     Text File bug6522_stacks.txt     PNG File image-2021-12-06-13-00-49-525.png     PNG File junos_yt800_heap.png     PNG File junos_yt800_perf.png     PNG File yt-692-desc-impl.png     PNG File yt692-heap.png     PNG File yt692-retained.png    
Issue Links:
Blocks
is blocked by YANGTOOLS-1066 SchemaPath identification of SchemaNo... Resolved
Relates
relates to YANGTOOLS-1348 Remove Binding-only constructs from Y... Confirmed
relates to YANGTOOLS-855 yang-maven-plugin scans dependencies ... Resolved
Epic Name: Parser Performance

 Description   

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?



 Comments   
Comment by Michael Vorburger [ 24/Aug/16 ]

Attachment SingleFeatureTest-Karaf-JavaFlightRecorder1118899505783732969.jfr.zip has been added with description: JMC

Comment by Michael Vorburger [ 24/Aug/16 ]

Attachment bug6522_stacks.txt has been added with description: Hot Methods Stack Traces

Comment by Peter Kajsa [ 24/Aug/16 ]

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.

Thanks.
Peter

Comment by Michael Vorburger [ 24/Aug/16 ]

> another separate, and bigger issue elsewhere - (...) 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.

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.

Comment by Michael Vorburger [ 08/Nov/16 ]

Linking CONTROLLER-1480 (just pointed out by Stephen in private emails), seems related..

Comment by Vratko Polak [ 08/Nov/16 ]

Similar symptoms were described here: https://bugs.opendaylight.org/show_bug.cgi?id=4462

Comment by Robert Varga [ 19/Dec/16 ]

The codebase has shifted significantly since August, so I would suggest collecting a new set of data from current master.

One problem identified, though, is SubstatementContext.isConfiguration(), this patch: https://git.opendaylight.org/gerrit/49567 should speed it up significantly.

Comment by Robert Varga [ 08/Jan/20 ]

So the heap/performance profile for Junos 19.3  with yangtools-4.0.4 looks like this:

which shows that:

  1. we processed the models in ~46 seconds
  2. peak memory usage was 2.7GiB
  3. final SchemaContext was ~1GiB

The primary cause of memory usage (and also CPU usage) is YANGTOOLS-694, which creates a lot of contexts during 'uses' propagation (~1.7GiB).

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:

in this case there are known invariants:

  • description is always declared
  • it typically does not have substatements (but it could have extensions)
  • its argument matches the declared statement

Hence there is room for improvement with regard to object layout, possibly with specializations.

 

Comment by Robert Varga [ 02/Sep/21 ]

With current yangtools-8.0.0-SNAPSHOT the performance looks much better:

Comment by Robert Varga [ 02/Sep/21 ]

Heap composition is also much saner, with SchemaPath objects gone and only about 10M objects.

Comment by Robert Varga [ 06/Dec/21 ]

With YANGTOOLS-1067 and a few other yangtools-8 deliverables we are down to ~3.5M objects.

Generated at Wed Feb 07 20:53:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.