Performance question, when a display name expression for a prominent action button is executed

I want to add some computed values to prominent action buttons, that are shown only on detail views. Hopefully they are executed on demand - but who knows - if they are executed on sync its a bad decision. Here is an example of such an display name expression on a button to a filtered view:

 

concatenate(
  "Reports (", 
  count(
    select(Table_Report[ID], 
      in([Table_Contract], 
        select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID])
      )
    )
  ), 
  ")"
)

 

Can anybody tell when these display name expressions on prominent action buttons are executed?

Solved Solved
0 6 249
2 ACCEPTED SOLUTIONS


@stefanasks wrote:

select(Table_Report[ID], in([Table_Contract], select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID]) ) )


FYI: in case you don't know already, nesting a SELECT() inside another SELECT() is pretty much the worst thing you can do for performance.  It's literally brute forcing the answer.

References to the rescue!

Add some reference connections between your tables (they might actually already be there) and you can accomplish the count() much more efficiently.

  • If your Report is connected to the Client,
  • and your Contracts are connected to Client,
  • then on Client you'll have two [Related whatever] columns, one for each.
  • [Related Table_Contract] is the field you'd want to count (if I'm reading your formula correctly)
  • You can use dereferences to get there from Reports
    • [Report_Client_Link].[Related Table_Contract]

This will increase the efficiency of the computation to a trivial thing, where you don't really need to consider it anymore.

Hope it helps!  Happy Apping!

View solution in original post

Your query might be simplified even more:

  • It looks like what you want is a list of all the reports for the client - yes?
    • If you add a ref connection into your Table_Report table to the Client table, then you'll have a [Related Table_Reports] VC on your clients table...
      • And this is the list you're looking to count.

This would remove all the brute force from the system, massively increasing your efficiency, at the cost of 1 duplicated data field.  #WorthIt

View solution in original post

6 REPLIES 6

Steve
Platinum 5
Platinum 5

Whenever the row is present in a view, even if off-screen.

Your expression is potentially very expensive and could affect battery life if not performance.

That's why ask this question.
So you say that these expressions are computed on render frame, in FPS manner like 60 times per second or at least on scroll screen?

I believe it's on scroll.


@stefanasks wrote:

select(Table_Report[ID], in([Table_Contract], select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID]) ) )


FYI: in case you don't know already, nesting a SELECT() inside another SELECT() is pretty much the worst thing you can do for performance.  It's literally brute forcing the answer.

References to the rescue!

Add some reference connections between your tables (they might actually already be there) and you can accomplish the count() much more efficiently.

  • If your Report is connected to the Client,
  • and your Contracts are connected to Client,
  • then on Client you'll have two [Related whatever] columns, one for each.
  • [Related Table_Contract] is the field you'd want to count (if I'm reading your formula correctly)
  • You can use dereferences to get there from Reports
    • [Report_Client_Link].[Related Table_Contract]

This will increase the efficiency of the computation to a trivial thing, where you don't really need to consider it anymore.

Hope it helps!  Happy Apping!

Thanks, I did not realize that I can use related columns as reference to replace a subselect. So I modified the query:

concatenate(
  "Reports (", 
  count(
    select(Table_Report[ID], 
      in([Table_Contract], [_THISROW].[Related Table_Contracts])
    )
  ), 
  ")"
)

Because in the related columns the subselect is already done, so no need to do it twice.

On the other hand, adding the grand parent ID as reference may blew up the sync process. Imagine 1000 clients with 10 contracts with 100 reports creates 1000 "Related Table_Reports" reference IDs in each client row. What makes 1.000.000 stored reference ids in the client table or about 20MB space only for packedUUID's - if I'm right.

Your query might be simplified even more:

  • It looks like what you want is a list of all the reports for the client - yes?
    • If you add a ref connection into your Table_Report table to the Client table, then you'll have a [Related Table_Reports] VC on your clients table...
      • And this is the list you're looking to count.

This would remove all the brute force from the system, massively increasing your efficiency, at the cost of 1 duplicated data field.  #WorthIt

Top Labels in this Space