[sedonadev] Link vs direct class variable access SVM performance hit

[keith bradley]

Good morning,

What is the SVM performance hit difference between using:

1> a link to pass a variable between two comp in the same kit

2> ... or a programmatic direct access of the other comp variable during execute call back (assuming scope set to kit wide).

I will have two comp in a kit that will work together and I am wondering if I should have the user wire a link? ... or set a slot to point to the instance and get it's variable that way.

There could be more than one pair of these linked components.

Which is more efficient and fast?

I hear links take alot of time for the engine to process.

Thanks!

[Murat Egrikavuk]

For programmatic access, you would need to refer to component path/name or componentId. Both of which, you cannot assume to remain constant across apps, builds, copy/paste operations etc.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+...@googlegroups.com.
To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

[keith bradley]

Thanks Murat!

For Copy/Paste operation it would be the responsibility of the user to set the correct "binding" on the new object pairs.

... but when you say:

" ... you cannot assume to remain constant across apps, builds,"

... do you mean a sedonaC compile from SAX to SAB?

On Mon, May 1, 2017 at 12:34 PM, Murat Egrikavuk <murat.e...@ontrol.com.tr> wrote:

For programmatic access, you would need to refer to component path/name or componentId. Both of which, you cannot assume to remain constant across apps, builds, copy/paste operations etc.

On Mon, 01 May 2017 20:25:57 +0300, keith bradley <kmbra...@gmail.com> wrote:

Good morning,

What is the SVM performance hit difference between using:

1> a link to pass a variable between two comp in the same kit

2> ... or a programmatic direct access of the other comp variable during execute call back (assuming scope set to kit wide).

I will have two comp in a kit that will work together and I am wondering if I should have the user wire a link? ... or set a slot to point to the instance and get it's variable that way.

There could be more than one pair of these linked components.

Which is more efficient and fast?

I hear links take alot of time for the engine to process.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.

[Murat Egrikavuk]

If the two components are in the same folder, the copy/paste operation includes the link as well. This is true whether you copy the whole folder (very useful in terms of portability of preconfigured strategies), or whether you select the two components only. At least in Niagara Workbench. I assume other tools will work similarly. In that case, the user need not worry about making a correct binding between the two components.

But no, I didn't mean from sedonaC compile from Sax to Sab. That wouldn't change to component Ids. However, as a general principle, I wouldn't rely on component Ids for passing variables between components. 

On Mon, 01 May 2017 20:40:56 +0300, keith bradley <kmbra...@gmail.com> wrote:

Thanks Murat!

For Copy/Paste operation it would be the responsibility of the user to set the correct "binding" on the new object pairs.

... but when you say:

" ... you cannot assume to remain constant across apps, builds,"

... do you mean a sedonaC compile from SAX to SAB?

On Mon, May 1, 2017 at 12:34 PM, Murat Egrikavuk <murat.e...@ontrol.com.tr> wrote:

For programmatic access, you would need to refer to component path/name or componentId. Both of which, you cannot assume to remain constant across apps, builds, copy/paste operations etc.

On Mon, 01 May 2017 20:25:57 +0300, keith bradley <kmbra...@gmail.com> wrote:

Good morning,

What is the SVM performance hit difference between using:

1> a link to pass a variable between two comp in the same kit

2> ... or a programmatic direct access of the other comp variable during execute call back (assuming scope set to kit wide).

I will have two comp in a kit that will work together and I am wondering if I should have the user wire a link? ... or set a slot to point to the instance and get it's variable that way.

There could be more than one pair of these linked components.

Which is more efficient and fast?

I hear links take alot of time for the engine to process.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+...@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+...@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+...@googlegroups.com.

[keith bradley]

lets say I had a drop down selection slot in Comp B (destination).

When the user added or removed any Comp A types (source of variable) ... the master list was updated.

Within each Comp B the user could select the desired source Comp A to create a pair.

If they copy and paste ... it would be their responsibility to set the new obj accordingly.

Maybe I leave the new Comp B with a null in that slot.

In that scenario ... would there be any problems?

If not ... would the SVM have better performance this way compared to using the link method?

I Every time I create a large app with many links and Comp ... the SVM engine scan gets slow.

Trying to explore more efficient ways.

Thanks Murat!

 

On Mon, May 1, 2017 at 12:47 PM, Murat Egrikavuk <murat.e...@ontrol.com.tr> wrote:

If the two components are in the same folder, the copy/paste operation includes the link as well. This is true whether you copy the whole folder (very useful in terms of portability of preconfigured strategies), or whether you select the two components only. At least in Niagara Workbench. I assume other tools will work similarly. In that case, the user need not worry about making a correct binding between the two components.

But no, I didn't mean from sedonaC compile from Sax to Sab. That wouldn't change to component Ids. However, as a general principle, I wouldn't rely on component Ids for passing variables between components. 

On Mon, 01 May 2017 20:40:56 +0300, keith bradley <kmbra...@gmail.com> wrote:

Thanks Murat!

For Copy/Paste operation it would be the responsibility of the user to set the correct "binding" on the new object pairs.

... but when you say:

" ... you cannot assume to remain constant across apps, builds,"

... do you mean a sedonaC compile from SAX to SAB?

On Mon, May 1, 2017 at 12:34 PM, Murat Egrikavuk <murat.e...@ontrol.com.tr> wrote:

For programmatic access, you would need to refer to component path/name or componentId. Both of which, you cannot assume to remain constant across apps, builds, copy/paste operations etc.

On Mon, 01 May 2017 20:25:57 +0300, keith bradley <kmbra...@gmail.com> wrote:

Good morning,

What is the SVM performance hit difference between using:

1> a link to pass a variable between two comp in the same kit

2> ... or a programmatic direct access of the other comp variable during execute call back (assuming scope set to kit wide).

I will have two comp in a kit that will work together and I am wondering if I should have the user wire a link? ... or set a slot to point to the instance and get it's variable that way.

There could be more than one pair of these linked components.

Which is more efficient and fast?

I hear links take alot of time for the engine to process.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.

To post to this group, send email to sedo...@googlegroups.com.
Visit this group at https://groups.google.com/group/sedonadev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sedonadev+unsubscribe@googlegroups.com.