Performance of creating ContentNode v. roArray/roAA

"malort" wrote:

"Veeta" wrote:
There is a new API in 7.6 that I'm hopeful will address this: ifSGNodeField.update.  In my experience, anything that can be done natively (vs. in BRS code) is a huge performance boost.  ifSGNodeField.update should be able to take ParseJSON output and convert it into a node tree in one call.

Yeah, that could definitely be  a useful performance boost to convert nodes containing roArray/roAA into nodes, but there are still some limitations there.
- The initial roAA won't be able to contain functional fields, unlike creating a custom node directly. This is the key benefit we've been looking for. If only RSG has first-class function support.
- You still need to set the roArray/roAA to a content node (deep-copy), then you can call node.Update() to convert the children.

Brightscript Debugger> a = { children: [ { id: "item1" }, { id: "item2" } ] }

Brightscript Debugger> print a
<Component: roAssociativeArray> =
{
    children: <Component: roArray>
}

Brightscript Debugger> u = CreateObject("roSGNode", "ContentNode")

Brightscript Debugger> u.update(a)

Brightscript Debugger> print u
<Component: roSGNode> =
{
    change: <Component: roAssociativeArray>
    focusable: false
    focusedChild: <Component: roInvalid>
    id: ""
}

Brightscript Debugger> print u.getchildcount()
 2

Brightscript Debugger> print u.getchild(0)
<Component: roSGNode> =
{
    change: <Component: roAssociativeArray>
    focusable: false
    focusedChild: <Component: roInvalid>
    id: "item1"
}

"malort" wrote:
I wonder if Roku is aware of this performance, and if this is going to be optimized in the future. No matter how you look at it, if you need to pass a lot of arbitrary data around, it's either going to be a bit slow to create the roSGNodes to use as a reference, or you end up running into performance issues with a deep-copy to read/modify arrays and associative arrays.

"RokuNB" wrote:

"malort" wrote:
I wonder if Roku is aware of this performance, and if this is going to be optimized in the future. No matter how you look at it, if you need to pass a lot of arbitrary data around, it's either going to be a bit slow to create the roSGNodes to use as a reference, or you end up running into performance issues with a deep-copy to read/modify arrays and associative arrays.

I think "the powers that be" are aware - but if you have partner support contacts, ring them up with this.

Also, how does `Node` fare in your tests - either as-is or extended? (`ContentNode` is a specialized sub-class of Node, required by many RSG APIs - but that does not mean it is required for own internal use)?

PS. what fw version? there is a chance benchmarks would differ 7.5 vs 7.6

"Veeta" wrote:
There is a new API in 7.6 that I'm hopeful will address this: ifSGNodeField.update.  In my experience, anything that can be done natively (vs. in BRS code) is a huge performance boost.  ifSGNodeField.update should be able to take ParseJSON output and convert it into a node tree in one call.

Brightscript Debugger> content = CreateObject("roSGNode", "node")

Brightscript Debugger> ?content.getChildCount()
 0

Brightscript Debugger> ?content.update()
Member function not found in BrightScript Component or interface. (runtime error &hf4) in $LIVECOMPILE(191)

"Veeta" wrote:
There is a new API in 7.6 that I'm hopeful will address this: ifSGNodeField.update.  In my experience, anything that can be done natively (vs. in BRS code) is a huge performance boost.  ifSGNodeField.update should be able to take ParseJSON output and convert it into a node tree in one call.

"malort" wrote:
- The initial roAA won't be able to contain functional fields, unlike creating a custom node directly. This is the key benefit we've been looking for. If only RSG has first-class function support.