sekur
commented
5 years ago Hi @quantang, thanks for this. Its perfect timing since this was exactly the area I’m currently working on optimizing. For one, I’ve recently shifted the internal List implementation to use Map instead of pure Array. This should help with the merge operation.
Another optimization is in how we handle “config false” data. In this case, instead of attaching Propertly instance to every node in the hierarchy, I just do a new .validate call which only performs schema validity test.
I also have added test cases to measure list operation timing data so I can track improvements along the way.
As it currently stands, the performance for larger set of list entries is subpar and I’m focused on optimizing it.
quantang
We are using yang-js to deal with network topology data and getting some performance issues when the amount of data reaches a certain level, such as we have a network entity which has 800 nodes and 2000 links. We did some perf profiling and identified the following potential improvements we may have:
Do not valid a "leafref" element if the "require-instance" is false. We have some "leafref" elements with "require-instance" false, however, the yang-js still takes a lot of time trying to find the matching entity, which could be skipped.
XPath.process function. There is a reduce function against data inside, which calls Array.concat function in the reducer function. It will take lots of time if the data is a big array, as the Array.concat will create a new array every time. I tried to refine it and push the new elements into an existing array, which makes it much better.
There is no key index for list element. The perf profiling shows some performance issue on Property.in and Property.merge, which should be related to that the yang-js does not have the internal key index for the list element. As it needs to iterate all the elements to make sure there is no duplicate key for the "merge" operation or find the right list item based on a given key for "in" operation.
Cheers.