Closed ThomasKientz closed 1 year ago
I don't see a delay
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.
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.
@KaelWD change [...Array(10).keys()]
from reproduction to [...Array(5000).keys()]
, and you will see the huge delay.
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.
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 ?
I had submitted this same issue at https://github.com/vuetifyjs/vuetify/issues/16220 and repro steps were added and rejected because @KaelWD stated that running in dev was not an acceptable way to test performance.
Tested this with the 3.1.0 release and same results.
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 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
@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.
Even worse with multiple
and 300 object items :
v3 https://codepen.io/thomaskientz/pen/wvxPLex
vs V2 : https://codepen.io/thomaskientz/pen/XWBzLeb
This is like five different problems all hitting at the same time:
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
Is it possible to specify height of opening items? Firstly, only few items will be loaded and after scroll rest of them?
Is it possible to specify height of opening items? Firstly, only few items will be loaded and after scroll rest of them?
We plan on integrating v-virtual-scroll
once it's out of labs.
As far as this issue is concerned, we have identified the root cause and are working on a fix now.
There is still a delay of more than one second if there are 1000 elements in the list. With vue2 there is a quick response. (vuetify 3.1.5)
Considering it hasn't been fixed that sounds about right.
I also noticed that navigation drawer with Expand on hover animation is lagging, side menu has around 150 items in sub groups list items
I also noticed that navigation drawer with Expand on hover animation is lagging, side menu has around 150 items in sub groups list items
The bug is related to v-list-item
and the places it's implemented.
@johnleider Has there been progress on the issue?
@johnleider Has there been progress on the issue?
As I understood (correct me if I'm wrong), the solution will depend on virtual-scroll. Virtual scroll is in Vuetify Labs, so I would expect a fully functional solution only after virtual-scroll is out of labs.
As I understood (correct me if I'm wrong), the solution will depend on virtual-scroll. Virtual scroll is in Vuetify Labs, so I would expect a fully functional solution only after virtual-scroll is out of labs.
This is correct. Although 3.1.9 did release with quite a few micro optimizations that do help.
How would we implement Vuetify Labs virtual-scroll with v-autocomplete currently?
How would we implement Vuetify Labs virtual-scroll with v-autocomplete currently?
You can't unfortunately. We are getting virtual-scroll into 3.2 and will update the select components proper soon.
The current plan is to release v-virtual-scroll
in v3.2. Once we have some testing in it and improve keyboard support, we want to release an update for all select components to implement the virtual scroller.
The current plan is to release
v-virtual-scroll
in v3.2. Once we have some testing in it and improve keyboard support, we want to release an update for all select components to implement the virtual scroller.
Will using v-virtual-scroll
in some components like autocomplete, combobox, etc. be in v3.2 or v3.3?
Given that the 3.2 is now out, and that I didn't see any mention of the v-virtual-scroller being used in the components in the changelog, nor in the code, and given that this issue has been assigned to 3.3, I'd say we're out of luck, and still need to wait a bit, am I right ?
This is the main reason we were waiting for the 3.2, but unfortunately, we'll have to be patient again... 😞
Given that the 3.2 is now out, and that I didn't see any mention of the v-virtual-scroller being used in the components in the changelog, nor in the code, and given that this issue has been assigned to 3.3, I'd say we're out of luck, and still need to wait a bit, am I right ?
This is the main reason we were waiting for the 3.2, but unfortunately, we'll have to be patient again... 😞
It will be patched as a fix in v3.2 since virtual-scroll is out of labs. It would have been nice to get it out today but we ran out of time.
I'm also still having issues with v-autocomplete in the 3.2.5 version. Even on 30 options, I have really annoying lag.
I'm also still having issues with v-autocomplete in the 3.2.5 version. Even on 30 options, I have really annoying lag.
If you're going to make a post saying "me too" please provide some sort of reproduction that differs from the current available. I highly doubt you're having lag issues with 30 items.
I'm also still having issues with v-autocomplete in the 3.2.5 version. Even on 30 options, I have really annoying lag.
If you're going to make a post saying "me too" please provide some sort of reproduction that differs from the current available. I highly doubt you're having lag issues with 30 items.
You are right. I just checked that I merged migration pull request few days ago. There are exactly 194 records and it feels laggy. I just tested, with 30 records it works fine, no lag at all
I'm also still having issues with v-autocomplete in the 3.2.5 version. Even on 30 options, I have really annoying lag.
If you're going to make a post saying "me too" please provide some sort of reproduction that differs from the current available. I highly doubt you're having lag issues with 30 items.
I check for releases every week and keep this test case of 5000 items current (Vuetify 3.3.1 as of today): https://codepen.io/jaysonpotter/pen/gOjLQRm
I'm also still having issues with v-autocomplete in the 3.2.5 version. Even on 30 options, I have really annoying lag.
If you're going to make a post saying "me too" please provide some sort of reproduction that differs from the current available. I highly doubt you're having lag issues with 30 items.
I check for releases every week and keep this test case of 5000 items current (Vuetify 3.3.1 as of today): https://codepen.io/jaysonpotter/pen/gOjLQRm
With 3.3.1 I can confirm that its working a LOT FASTER! loading 300 or 500 records is instant. on 1500 records its barely lagging.
Everyone here please try the nightly build from https://github.com/vuetifyjs/vuetify/pull/17265#issuecomment-1564103553
https://vuetifyjs.com/en/getting-started/installation/#nightly-builds
The nightly build is awesome and perfecly responsive. Unfortunately, the 3.3.2 version is still slow and laggy. I will continue to be patient.
The cause of the lag maybe for the large set of data, you can use v-intersect to implement infint scroll in v-autocomplete too. Why waiting for this issue here?
This isn't going to be merged until I get some positive feedback that it doesn't break anything else. There's 18 people in this thread and I've only heard from one two.
Run it in production even, it's otherwise identical to 3.3.2
I don't see a performance difference between 3.3.2 and @vuetify/nightly@3.3.0-master.2023-05-21
-- am I on the right nightly version?
No: https://github.com/vuetifyjs/vuetify/pull/17265#issuecomment-1567258080
npm i vuetify@npm:@vuetify/nightly@3.3.2-pr-17265.4b7bc69
Autocomplete in 3.3.2-pr-17265.4b7bc69 is blazing fast and responsive with my 10k entries test case. My other test examples with advanced usage (multiple overriden slots, html option, icons), seem to work fine.
LGTM
I feel more faster after 3.3.2
Went searching for performance issues with V3 autocomplete and found this thread. My autocomplete has 820 items in it using custom templates. In V2 its instant to open/display. In 3.3.2 and the nightly build listed above it takes around 2 seconds to open. There is no difference between 3.3.2 and the nightly that I can discern.
Make sure you have it installed correctly, it should replace the normal vuetify version.
I don't think I was using vuetify/nightly@3.3.2-pr-17265.4b7bc69. Thanks for the push to try it again. This performs much better, instantaneous. Thanks again.
@KaelWD when the items are loaded while the menu is open it won't observe for changes.
I have a component that loads the items only after the input is focused for the first time. The scroll is getting the correct height, but only the first few items are rendered.
If I close the menu and open again (with the items already loaded) it works just fine.
Also, is it possible to create a "list" slot, that allows one to completely replace the rendering logic of the list but still taking advantage of the component methods?
Should be fixed now, try the new build
is it possible to create a "list" slot
Thank y'all for the updates, but still appears to lag @ v3.3.3: https://codepen.io/jaysonpotter/pen/gOjLQRm
@KaelWD it's flying now, nicely done!
@jaysonpotter your pen is at the wrong version. You should test with @vuetify/nightly@3.3.3-pr-17265.321510f
since this PR is not merged yet.
Here is your test with the latest build on that branch https://codepen.io/SkyaTura/pen/zYMxQjP
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.