Optimizing the time spent to create the OPC UA node tree

[stenil]

Hi,
at startup of our application we read a configuration in XML format and the parsed data is used to create the OPC UA node tree.
When testing with large (lets say around 800 000 OPC UA variables in an hierarchy of folders) configurations, the configuration phase takes longer time than what we wish for.
Time is spent in our own application code parsing XML etc, but also in the NodeManagerUaNode:addNodeAndReference calls and in the construction of OpcUa::BaseDataVariableType.

I have used callgrind/KCachegrind for the analyze.

If we were to have a pool of threads to create different parts of the node tree using our node manager, that should work I guess (BaseDataVariableType has a mutex to control access to one single variable but I see nothing about locking on other level)?

Are these SDK calls (NodeManagerUaNode:addNodeAndReference , BaseDataVariableType()) executing in our application thread(s) or is the work dispatched to internal SDK threads?

BR,
Stefan

[Support Team]

Hello Stefan,

I don't expect that calling addNodeAndReference from multiple threads in parallel will increase performance in any way.
How did you set the hashtable size for your NodeManager?
You should set it to a number significantly bigger than the total number of nodes you add to that specific namespace (e.g. 2.000.000 in your case).

see here:
http://documentation.unified-automation ... 46a04cadda

[stenil]

Thank you!
I tried your suggestion (we used default size 10003) and now the phase where we (in this case with some 640 000 variables) create the nodes (and do other stuff also) went from 44 s to 16 s !

Once again, thanks for a great advice.

BR,
Stefan

[stenil]

Hi,
one question:
Should the increased hashtable size also affect performance after the variables have been created, e.g. read/write variable performance?

BR,
Stefan

[Support Team]

Hello Stefan,

if the bucket size in a HashTable gets bigger the time to lookup also grows.
This has an effect on creating nodes and also on NodeId lookup during runtime (e.g. used when read and write service is called).
However I wouldn't expect the read/write performance to get significantly better since the lookup of NodeIds is just one part of the overall work that needs to be done for read / write service call.