[Bug Report][3.1.2] Autocomplete feels laggy

[ThomasKientz]

Environment

Vuetify Version: 3.0.5
Last working version: 2.6.13
Vue Version: 3.2.45
Browsers: Chrome 108.0.0.0
OS: Mac OS 10.15.7

Steps to reproduce

Use a VAutocomplete.

Expected Behavior

When user focus, list menu to appear instantly, as with Vuetify 2.

Actual Behavior

When user focus, list menu appear with a delay (100-200ms ?).

Reproduction Link

https://codepen.io/thomaskientz/pen/vYaOgwO?editors=1010

Other comments

Vuetify 2 exemple : https://codepen.io/thomaskientz/pen/dyjoNEb?editors=101

I think its a bug of the animation. With a VSelect it's fine, the animation is too harsh though imo.

Also, looks like its fine when VAutocomplete is instantiated with a value.

[KaelWD]

I don't see a delay

[mgd216]

I'm having similar issues with VAutocomplete, I have an items list of over 800 items with title and value props. Typing in the autocomplete to filter has a severe delay. However when I try and repdroduce the issue in Codepen, the Autocomplete filters fine with 500 objects:

https://codepen.io/mgd216/pen/poZyeBa?editors=1010

I'm using Vue 3.2.45, Vuetify 3.0.6 with Nuxt 3.0.0. I'm trying to determine if Nuxt is layering some action over Autocomplete that is bogging it down.

[luiztsmelo]

I'm having a huge delay with v-autocomplete too with big lists, even crashing the App for a while, after migration.

Vue: 3.2.45
Vuetify: 3.0.6

PS: I'm not using Nuxt.

[luiztsmelo]

@KaelWD change [...Array(10).keys()] from reproduction to [...Array(5000).keys()], and you will see the huge delay.

[KaelWD]

I'm aware of problems with large numbers of items, trying to get #15585 in 3.1 to resolve that. @ThomasKientz didn't specify more than 10 items so idk if this is something else.

[ThomasKientz]

I was having issue with 10 elements only. I have pinned the exact version of vuetify in the repro, but you are right no delay / issue with animation anymore. Menu was hiding the label as well, not the case anymore. Maybe a cache issue on my side.Do you guys want I keep the issue open for large list ?

[jaysonpotter]

I had submitted this same issue at #16220 and repro steps were added and rejected because @KaelWD stated that running in dev was not an acceptable way to test performance.

[jaysonpotter]

Tested this with the 3.1.0 release and same results.

https://codepen.io/jaysonpotter/pen/gOjLQRm

[drhouse82]

I agree that there is a big issue with large autocomplete opening times.
@KaelWD Merging #15585 did not really improve the situation, right?
For me, the codepen autocompletes of @mgd216 take 2-3s to open, in the last codepen of @jaysonpotter the autocompletes don't open at all.

[boukadam]

I agree that there is a big issue with large autocomplete opening times. @KaelWD Merging #15585 did not really improve the situation, right? For me, the codepen autocompletes of @mgd216 take 2-3s to open, in the last codepen of @jaysonpotter the autocompletes don't open at all.

I'm using the last release v3.1.1 and I am having the same issue with VAutocomplete having data of around 40k items

[ThomasKientz]

@KaelWD still happening with 3.1.2 (and in current nightly) : you can reproduce with : https://codepen.io/thomaskientz/pen/PoBOvNN and compare with https://codepen.io/thomaskientz/pen/xxJPNGQ

V3 feels laggy.

[ThomasKientz]

Even worse with multiple and 300 object items :
v3 https://codepen.io/thomaskientz/pen/wvxPLex
vs V2 : https://codepen.io/thomaskientz/pen/XWBzLeb

[ThomasKientz]

autcomplete-v3.1.2.mov

[KaelWD]

This is like five different problems all hitting at the same time:

• connectedLocationStrategy calls itself twice (fix(VTooltip): display intrinsic maximum width content #16350)
• useLocationStrategies also initialises itself twice, so updatePosition is called four times
• all list items are always rendered ([Bug Report] V-Select scrolling behaviour #2660)
• list items render twice initially (fix(groups): use suspense to delay rendering of group items #15215)
• the way we retrieve prop defaults is inefficient and results in lots of proxy calls on patches

[yuwu9145]

Even worse with multiple and 300 object items : v3 https://codepen.io/thomaskientz/pen/wvxPLex vs V2 : https://codepen.io/thomaskientz/pen/XWBzLeb

After playing around, although locationStrategies needs to be optimized, it doesn't delay that much and the major delay seems to be caused by "rendering" itself. In V3, it renders whole list once (which could cause huge delay for nextTick depends on how many items to render), but in V2, its initial rendering only renders first 20ish items and gradually renders more while scrolling.

I mean making a lazy loading effect #2660 for V3 could be the one that can make significant difference here as a first step quick win

[SkyaTura]

@gabaum10 have you tried installing with npm install --save vuetify@npm:@vuetify/[email protected]?

Saw the update haha

---

I did some experiments on the links sent by @gabaum10 @acnowland and it is, indeed, opening and scrolling as expected. However, when pushing things further to explore the limits on this matter, I found that after typing something and clearing back, it freezes for a couple instants before actually clear the input.

As far as I went, the PR seems fine, it is definitely way better than current release, and I don't really think that autocompletes should be used on 10k arrays, however, this may be a point of attention.

[gabaum10]

Yeah as @acnowland mentioned, it's working much better on our live example. This should be good. We'll run the nightly for now as we finish the migration and let you know if we see anything weird.

Do you guys know when this fix will get pushed out?

[KaelWD]

If anyone else is having problems with installation, make sure to

1. Replace vuetify with the nightly build, do not install them both. This should be done with a package alias so all the import paths are unchanged, see the diff under https://vuetifyjs.com/en/getting-started/installation/#nightly-builds for an example.
2. Use the correct build, it should contain <version>-pr-17265.<hash> not <version>-master.<date>

---

Notice the massive scrollbar, which means all 3000 of the items are being populated into the menu.

It will have a massive scrollbar when it's working correctly too, the extra space is just reserved by a single element instead of hundreds.

---

after typing something and clearing back, it freezes for a couple instants

@SkyaTura Do you have some code and exact steps to take to reproduce this?

---

when this fix will get pushed out?

@gabaum10 When I'm satisfied that it isn't significantly broken.

[KaelWD]

@SkyaTura Fixed, filtering should be more than 30x faster now for 50k items, 240ms -> 6.5ms. Even 500k items takes under 200ms.

[acnowland]

@KaelWD so it is working better but not great in our application.. now I cant replicate it though but we are using the PR build b/c it load smuch quicker, but the issue is on scroll. The items load quick initially but as we scroll there is a delay from when you scroll and when they are rendered. I was doing some performance testing and unsure if related, but if you compare the old in v2 vs v3 we can see that in the PR version it is literally firing off THOUSANDS of event listeners as you scroll. While in the old it fires only 2 each time you scroll. I imagine this can lead to some performance issues. Not sure if fixed already or not.

v2:

v3:

v2 was taken from our prod application so there is other stuff going on there, v3 was recorded though in the playground on the pr17265 branch, but it can be noted that both contain the same data points, its taken from the example we posted above using the PR build

[acnowland]

any updated on my concern? its an awful lot of listeners being triggered on scroll with the new implementation vs the old. We are also seeing some kind of weird interaction with building our project with that nightly PR included with this fix. For w/e reason on a local dev server we see the full list of items being rendered as you scroll, but after we deploy it only renders 30-50% of the items. I can inspect the autocomplete after deploy and see the :items have been passed in, and you can even search for the hidden items and they appear, but as you scroll they do not render.. I cannot for the life of me replicate on a playground though and also not sure if its build related on our side or something from vuetify side tbf.

vuetify: "npm:@vuetify/[email protected]"

Thats the build we are using which I think is correct. I realize w/o a replication its tough, but figured it should be brought to attention

[KaelWD]

I'm not seeing thousands. Each step here is one scrollwheel notch, then I closed the menu, waited a couple seconds, and triggered GC:

This is scrolling all the way to the end, back to the top, then triggering GC:

The reason it doesn't drop as soon as the menu closes is probably just v8 being efficient and not cleaning up until it actually runs out of memory.

The retained memory seems to be effect dependency arrays in the scope of this vue internal function I think?

I'm guessing that would be cleaned up after the autocomplete unmounts.

after we deploy it only renders 30-50% of the items

I actually reproduced this by accident trying to see if the memory behaviour was different in a production build (because that closure wouldn't exist), looks like it's getting window as the scrollable parent instead of the list for some reason.

[KaelWD]

vm.ctx.$el is only defined in dev: https://github.com/vuejs/core/blob/020851e57d9a9f727c6ea07e9c1575430af02b73/packages/runtime-core/src/component.ts#L572-L576

This is the second test again but in a prod build, seems to collect partway through scrolling and doesn't retain anything after the manual GC:

It does peak at 50k listeners but there's 50k items so that makes sense.

as we scroll there is a delay from when you scroll and when they are rendered

Do you mean this?

Kooha-2023-06-15-16-24-24.mp4

That's expected, scrolling runs on a separate thread and if you scroll too fast the main thread can't keep up. We could render like three extra pages of items just in case but that's a lot of overhead.

[KaelWD]

It might be possible to shift the window based on scroll velocity though.

[acnowland]

Thanks for all of the investigation @KaelWD , yea the description makes sense, I wonder if i see alot more since I am using a trackpad to scroll? Not sure, but overall you are right, it doesn't seem to degrade the actual performance. Also, amazing that you happened to reproduce the bug in prod where its not capturing the right scrollable window. Honestly once that is resolved I think everything should be good.

[johnleider]

It might be possible to shift the window based on scroll velocity though.

Such as increasing the buffer on either side depending upon how fast the user is scrolling?

[gabaum10]

Hey is there any way we can get a timeline update for this? It's one of the last major pieces we're waiting for from the v2 -> v3 migration. We also would like to make use of the two patches the PR nightly is behind for this as the fixes within address some of the other issues we've had to work around.

[johnleider]

Hey is there any way we can get a timeline update for this? It's one of the last major pieces we're waiting for from the v2 -> v3 migration. We also would like to make use of the two patches the PR nightly is behind for this as the fixes within address some of the other issues we've had to work around.

This is the timeline: #17265

[gabaum10]

@johnleider is there any way we can get an up to date nightly for that PR published? The one we've been testing is weeks old.

There is absolutely no way we can wait around until September for 3.4 to roll out the upgrade for this fix. As is, all additional development is currently on hold while we iron out the remaining Vuetify 3 issues, this being one of the biggest ones.

[johnleider]

It's marked for v3.4 but it's based off of master. Once @KaelWD collects enough feedback to feel comfortable with shipping it, we'll merge and release as part of a regular weekly patch.

[gabaum10]

Great, thanks! As soon as we can get an updated nightly build off that PR to test the other reported issue it'll probably be good on our side. But we're waiting to confirm.

[KaelWD]

@gabaum10 I've published another one with the latest changes

[Rusinas]

@KaelWD thank you for you work, now it's much better. Unfortunately, virtual scroll doesn't work in production for some reason. After vite build it looks like this:

[gabaum10]

@KaelWD thank you for you work, now it's much better. Unfortunately, virtual scroll doesn't work in production for some reason. After vite build it looks like this:

This is the same issue we were hoping that was fixed by the changes in the PR. I guess it's not though. I'm not entirely sure how to replicate it, but we will work on trying to come up with an example in the playground.

[gabaum10]

@KaelWD FYI, I'm not seeing the issue reported above. I suspect they are still using the old version of the build. As far as I can tell, all our issues are now resolved. This is great. Thanks for your work on this stuff!

[johnleider]

Thank you everyone for your patience on getting this tested proper. It will be in your hands very soon.

[acnowland]

Yea this looks great now! Thank you all! 🙏🏻

[Rusinas]

@gabaum10 the build I'm using is [email protected]. Did I miss an update?

[gabaum10]

@Rusinas yes. "vuetify": "npm:@vuetify/[email protected]"

[Rusinas]

Yep, it works now, thank you so much!