regarding performance for local variable

Hi All

In 1st local variable i am calling an exprission rule and getting the data 

In 2nd local variable i am using UNION(local!associatedCompanies1,local!associatedCompanies1)

but why the execution time is more for 2nd variable 

I thing this expression rule is calling second time in 2nd variable

can any one tell me why it is happning 

  Discussion posts and replies are publicly visible

Parents
  • It's a little hard to tell without a bit more information (what is the SAIL for your interface? what is the expression rule called in the first variable?), however a couple general suggestions:

    • Use variables that don't refresh as much as you can. Basically, don't use with() or refreshAlways in a!localVariables().
    • Union can be a slow operation depending on the data. One way to make it faster is to union against a null list instead of against the same data again. Here's an example:

    union(local!associatedCompanies, touniformstring({}))

  • A Score Level 2
    in reply to Peter Lewis

    a!refreshVariable(value: 
    local!associatedCompanies ,refreshOnReferencedVarChange:false),

    this is not working i am using appian 20.1

  • Certified Lead Developer
    in reply to Nikkheel

    Can you provide more context?  Are you defining a new local variable here or what?  This doesn't look like a valid use of a!refreshVariable otherwise.

  • a!localVariables(

    local!associatedCompanies1: rule!PROXY_PXY_watchlistData(
    Ids: local!ColumnOne
    ),
    local!associatedCompanies:union(local!associatedCompanies1,local!associatedCompanies1),)

  • Certified Lead Developer
    in reply to Nikkheel

    First things first - should the value of local!associatedCompanies1 update automatically if local!ColumnOne changes?

  • no I have kept a!refreshVariable(value:local!columnOne,refreshOnReferencedVarChange: false)

  • Appian Employee
    in reply to Nikkheel

    Could you just post the whole SAIL of your interface? It's really hard to follow a snippet at a time. Also, can you clarify where you are seeing this degredation in performance? Is it only slow loading the page, or is it slow with every interaction? If it's only slow when loading the page, then I don't think you are having any issues with refreshVariables.

  • Certified Lead Developer
    in reply to Nikkheel
    no I have kept a!refreshVariable(value:local!columnOne,refreshOnReferencedVarChange: false)

    I agree with Peter, we need to see larger context (your whole interface, preferably) - the snippet you've provided here again doesn't represent how a!refreshVariable() actually works, so it would be useful to see exactly how and where you're using it in bigger-picture context.

  • A Score Level 2
    in reply to Peter Lewis

    a!localVariables(
    local!addEditGridSelection: a!gridSelection(
    pagingInfo: a!pagingInfo(
    startIndex: 1,
    batchSize: 10,
    sort: a!sortInfo(
    field: "issuerPublishedReportingName",
    ascending: true
    )
    ),
    selected: null
    ),
    local!excel: a!refreshVariable(
    value: if(
    isnull(
    ri!document
    ),
    {},
    readexcelsheet(
    excelDocument: ri!document,
    sheetNumber: 0,
    startRow: 1
    ).result
    ),
    refreshOnReferencedVarChange: false
    ),
    local!columnOne: a!refreshVariable(
    value: a!forEach(
    local!excel,
    index(
    fv!item.values,
    1,
    null()
    )
    ),
    refreshOnReferencedVarChange: false
    ),
    local!excelColumnOne: a!refreshVariable(
    value: touniformstring(
    local!columnOne
    ),
    refreshOnReferencedVarChange: false
    ),
    local!associatedCompanies1: a!refreshVariable(
    value: rule!PROXY_PXY_watchlistProcessExcelData(
    excelData: local!excelColumnOne
    ),
    refreshOnReferencedVarChange: false
    ),
    local!associatedCompanies: union(
    local!associatedCompanies1,
    local!associatedCompanies1
    ),
    local!notPresentList: reject(
    fn!isnull,
    difference(
    local!excelColumnOne,
    local!associatedCompanies
    )
    ),

    {................}

    )

  • Certified Lead Developer
    in reply to Nikkheel

    I don't see any obvious errors. And if "ri!document" won't be changing dynamically, then none of the "refreshOnReferencedVarChange: false" calls should even be needed, since (as far as I can see) there isn't any other way that those would try to refresh.

    As a personal best practice I always set up a utility rule in my environment to handle deduplication of a given array, i.e. rule!GLBL_removeArrayDuplicates() which just does union(ri!array, ri!array) inside, so that in my interface I don't have to declare a dummy variable (local!associatedCompanies1) just to union it to itself in the "Real" variable -- instead the query itself could be wrapped in the above helper rule.

Reply
  • Certified Lead Developer
    in reply to Nikkheel

    I don't see any obvious errors. And if "ri!document" won't be changing dynamically, then none of the "refreshOnReferencedVarChange: false" calls should even be needed, since (as far as I can see) there isn't any other way that those would try to refresh.

    As a personal best practice I always set up a utility rule in my environment to handle deduplication of a given array, i.e. rule!GLBL_removeArrayDuplicates() which just does union(ri!array, ri!array) inside, so that in my interface I don't have to declare a dummy variable (local!associatedCompanies1) just to union it to itself in the "Real" variable -- instead the query itself could be wrapped in the above helper rule.

Children
  • Yeah seems fine to me. I'd still suggest using union(local!associatedCompanies1, touniformstring({})). If you're really worried about performance that should make a minor difference. Otherwise, I'd suggest looking into the supporting rule that generates the results for local!associatedCompanies1 to see if there are any improvements you could make there.

  • Certified Lead Developer
    in reply to Peter Lewis

    Awesome suggestion, Peter.  If at all possible, you're more likely to get way better performance out of convincing your data source to eliminate the duplicates for you, rather than asking Appian to do it after you've already ferried all the extra data over.  Returning the smallest amount you can from DB is a standard best practice.

    Of course it ultimately depends on how your expression gets the data in the first place.