Arcade Performance: FeatureSetByRelationshipName vs. FeatureSetByName

FabianHannich

 

I am currently working with Arcade expressions in attribute rules and have come across a performance-related question for which I haven’t yet found a clear comparison in the community.

 

Initial situation:

I am working with the following feature classes and tables:

• Address
  Fields: aId (PK), from_number, sId (FK)
• Street
  Fields: sId (PK), name
• Status
  Fields: aIdORsId (FK), status, type

 

Relationships:

• Address – Status (1:1)
• Street – Address (1:n)
• Street – Status (1:1)

I would like to create an attribute rule on the Status table:

If:

• type = "Address" and
• status = "Error"

then the status of the related Street should also be set to "Error".

 

Implementation approaches:

Option 1: Using FeatureSetByRelationshipName

var addr = First(FeatureSetByRelationshipName($feature, "Address-Status"))
var str = First(FeatureSetByRelationshipName(addr, "Street-Address"))
var stat = First(FeatureSetByRelationshipName(str, "Street-Status"))

Option 2: Using FeatureSetByName

var addr = First(FeatureSetByRelationshipName($feature, "Address-Status"))
var statFs = FeatureSetByName($datastore, "Status")
var stat = First(Filter(statFs, 'aIdORsId = @addr.sId'))

 

Question:

Which approach is more performant?

I am particularly interested in:

• Should FeatureSetByRelationshipName generally be preferred when relationships are available?
• How much does the number of FeatureSet calls impact performance?
• Is a combination of FeatureSetByRelationshipName and FeatureSetByName problematic in terms of additional requests?

DavidSolari

If you aren't tallying up CPU instructions, the answer to "which option is more performant" is always "the one that ran the fastest in testing." Build up a representative dataset, move it to a testing clone of your usual RDBMS setup, load that into a copy of Pro on a free machine and then run some tests. For each attribute rule you'll want to run a bulk update, measure the time it took, reset the state of the test data outside of this time measurement, then run that entire test multiple times so you can average out external performance concerns. Then you just use whatever wins! Like @VenkataKondepati mentioned, option 2 is tougher to maintain in the future, so if that wins I recommend leaving a big fat comment in the attribute rule that explains what's going on and also includes option 1 for reference.

Some resources for building your test runs:
Update Cursor (to change an attribute and trigger the rule)
Editor (to ensure the updates are processed in the same edit session)
time.perf_counter (call this before and after the edit session, then do after - before to get a value of elapsed time. Always use counters like this instead of standard datetime functions to measure performance as they're more accurate and are unaffected by world clock synchronization)