Roku Developer Program

[malort]

One thing to be cautious of is the performance of creating many nodes/contentNodes as they are quite a bit slower than the standard roArray/roAssociativeArray. See the example below

This is the time it took to create 2000 objects of each type.

CreateObject("roSGNode", "LargeContentNode")  1324ms
CreateObject("roSGNode", "BaseContentNode")  649ms
CreateObject("roSGNode", "ContentNode")  92ms
AssocArray:  3ms
Array:  4ms

The interesting bit is how long it took to create 2k BaseContentNodes as it's just a simple extended ContentNode with no additional fields/functions/children. The large content node had a lot of fields and functions.

<?xml version="1.0" encoding="utf-8" ?>
<component name="BaseContentNode" extends="ContentNode" />

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.

[NB_]

"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

[malort]

"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

I didn't mean to hijack the thread, so sorry about that.
We did try using `Node` instead of `ContentNode`, but the difference was marginal. This was tested on 7.5 and 7.6 with no change in performance between the two.

[Veeta]

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]

"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.

I'm running 7.6 right now, but node.Update() doesn't seem to be working at all. Maybe I should finish my morning coffee.

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]

"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.

Your second point is not correct.  You pass the source AA as an argument to update().  The following works for me on 7.6:

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]

Ah, there you go 🙂  the parameter and structure of it was the missing part - not sure how I missed the docs link on that, oops. Interesting feature.

[NB_]

"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.

I don't see how this relates to @malort q?
.update() seems to be a method related to .addFields()/.setFields()/.append() and does not promise to do any conversion to nodes.
I am baffled myself what the difference between .update() and .setFields() is?

[NB_]

"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.

Not only initial roAA but in general RSG node fields currently cannot contain 1st-class function references at any level.
That is again a different - and important! - question. I suggest opening a new thread on this and also contact Roku Partner Support on this.