Performance of queryEntity and custom picker for large dataset

Hello,

I'm trying to configure a custom picker on a large dataset,  ~7100 values.

The first problem I'm encountering is that the queryEntity() by itself takes ~8.5 seconds to complete.
May this be due to the fact that the CDT of the DSE has nested CDTs? I'm confused, because the query completion in MySQL is almost instantaneous. What's taking so long?

The second problem is that, even by loading the entire dataset in a local variable, the custom picker I configured is extremely slow during search operations, to the point that it triggers the browser's checks for unresponsive Javascript.

I'm using the following rule as filter, passing my labels and values:

=with(
  local!matches: where(
    a!forEach(
      items: ri!labels, 
      expression: search( ri!filter, fv!item)
    )
  ),
  a!dataSubset(
    data: index( ri!labels, local!matches), 
    identifiers: index( ri!identifiers, local!matches)
  )
)


Question 1) If I refactor my CDT not to contain nested types, what can I reasonably expect as a loading time?
Question 2) Is a custom picker expected to work on 7k values, and if so, how can I improve its performance?

I'm trying to understand if my efforts will ever make the picker usable, or if maybe these numbers are too high and I should change approach for having my users select values.


I can provide additional information if needed.

Thanks in advance.

  Discussion posts and replies are publicly visible

Parents
  • 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!

  • 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.

Reply
  • 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.

Children
No Data