Performance of queryEntity and custom picker for large dataset

RE: Performance of queryEntity and custom picker for large dataset

Peter Lewis — Wed, 10 Jun 2020 11:49:29 GMT

I like that idea to only perform the search if at least 3 letters are entered! You could also limit it on the other side - for example, only return the first 20 items that match to display in the picker.

One other thing I have tried before too is to use a text field and a search button for this use case. It isn't quite as seamless as a picker, but you will ensure better performance because you only perform the search on click of the button. Plus, you can display the results in a grid, which would allow you to use paging if there are too many results.

RE: Performance of queryEntity and custom picker for large dataset

scristalli — Wed, 10 Jun 2020 07:52:37 GMT

Thank you Mike and Peter for the suggestions. Selecting columns was the key to boost the performance of the QueryEntity, which now takes milliseconds to execute.
Afterwards, I still had the problem of the custom picker, as typing a single letter would result in loading a large number of items, still freezing the Javascript.

For the moment, I solved by editing the expression rule I posted by not performing any search if the length of ri!filter is less than 3.
In our particular use case, at the moment this solution is acceptable for end users, considering both UX and performance.

If there is a better method to solve the issue, please suggest and I will be happy to try!

RE: Performance of queryEntity and custom picker for large dataset

Peter Lewis — Fri, 05 Jun 2020 13:30:26 GMT

What kind of nested CDT do you have? If you have a nested 1:M, this can have potential performance problems because it queries the parent data and queries for each of the children values separately: see the CDT Guidance in the documentation. Also, do you actually need the nested data in your query or can you just select columns from the parent like Mike suggested?

RE: Performance of queryEntity and custom picker for large dataset

Mike Schmitt — Fri, 05 Jun 2020 12:41:23 GMT

7K values does not seem large enough by itself to be causing such stress to queryEntity. Is it a view with very cumbersome joins, or something?

I would concentrate on figuring out the QueryEntity performance gap before worrying about the custom picker. Out of curiosity, does the performance of the query operation improve significantly if you pull only a few columns, instead of the whole CDT?