Performance issue with autocomplete when the data array is very large.

[seedds]

Overview of the problem

Oruga version: [0.9.0-pre.1] Vuejs version: [3.5.4] OS/Browser: windows/chrome

Description

Performance of Autocomplete is very bad when the data is very large. I have an array which contains around 1000 strings. It feels very laggy when using the Autocomplete component.

Steps to reproduce

The base example on the page: https://oruga-ui.com/components/Autocomplete.html. First fill the data object with random string data. When the data object is large enough, the performance drops significantly.

Expected behavior

the filter function should perform very smoothly and feel snappy.

[mlmoravek]

Hey, I don't know if this is a real oruga issue or a vue issue.

The options are filtered by a change of the input value:

props.options.filter((option) =>getValue(option).toLowerCase().includes(vmodel.value.toLowerCase())),

You can provide your own filter function with the prop filter, if you have a more complex filter logic.

---

However, feel free to make a PR with an improved implemenation.

I would suggest just filtering your options by some pre-selection by the user beforehand.

[seedds]

It may be an oruga issue. Since I use Select component in Quasar at last, it is very snappy with the same data.

I made a code snippet to demonstrate the problem at https://codesandbox.io/p/sandbox/oruga-test-ktvqlg The array is 1000 length. when you select an item, then try to delete it. It will take seconds to complete. Or you enter one character, then tried to delete it, it will also take seconds to complete.

[mlmoravek]

Hmm ok, I did some investigating and agree, we could do some performance improvements here.

[seedds]

Great. Thank you very much.

Another problem I encounter when I am doing last project is that the memory usage of Table component was keeping growing when the data source of the table was updated probably once per 2 seconds.

I was using Websocket to get new data for a table about once per 2 seconds. During that process, the heap size kept growing larger and larger until the whole page crashed. I tried many ways to isolate the problem. In the end, I suspect that something in the Table component might be not properly destroyed when new data came and DOM refreshed.

I ended up using Table component from Quasar to solve the problem. The heap size used by Quasar component is about 40-50MiB, and it was very stable. Compared with Table component in Oruga, the heap size grew from 100 to 3000MiB, then crashed inevitably.

[mlmoravek]

Thanks for reporting this! I will check this. Could you make a reproducible example of the table problem?

[seedds]

I make an example at https://codesandbox.io/p/sandbox/oruga-table-test-vzcjk3?file=%2Fsrc%2FApp.vue I have to open https://114.132.182.150:59888/get_quote at my browser first to proceed with unsafe cert, since it is an adhoc ssl flask server hosted at my own computer. Otherwise, the axios can't make http request in codesandboxie.

The memory usage grows steadily. The memory usage goes over 1000MiB or 2000MiB with 3 or 4 tables like this. After switching to Quasar, I noticed that the memory usage is very low, which rarely goes over 50MiB.

I made a similar table in Quasar at https://codesandbox.io/p/sandbox/quasar-table-test-4rh6dz?file=%2Fsrc%2FApp.vue%3A31%2C59 You can see that the memory is very stable. And in production the memory usage is below 50MiB, the 300ish memory usage is probably due to the overhead of codesanboxie