[Bug Report][3.0.3] v-autocomplete performance

[jaysonpotter]

Environment

Vuetify Version: 3.0.3 Last working version: 2.6.12 Vue Version: 3.2.45 Browsers: Chrome 108.0.0.0 OS: Mac OS 10.15.7

Steps to reproduce

fullscreen sandbox preview

Click on the autocomplete input at the very top of the page. Make a selection and try to make another selection.

Expected Behavior

Focusing on the v-autocomplete input, and making selections, be snappy and responsive.

Actual Behavior

My results in Chrome is that the page busts and gets reloaded. In other browsers it is slow to respond in both focusing on the input and making a selection.

Reproduction Link

https://codesandbox.io/s/vue-3-vuetify-3-pinia-2-hkzluk

Other comments

The key is to have at least 500 items fed to the v-autocomplete. I have rendered 5000+ using the same component in v2.6.12 without issue, but even rendering 500+ has a noticeable performance hit in v3.

In my example, originally created using npm create vuetify, I am using the same API used in the Vuetify autocomplete documentation, https://api.publicapis.org/entries, and trying to render the entire list of 1400+.

Thank y'all for any attention on this!

[mgrubb]

I'm also experiencing this but with far fewer entries, 39 to be precise. Even if I hard code those entries into my component instead of fetching them from the API or cache it takes about ~1-1.5 secs for the menu to show. Same version of vuetify.

[KaelWD]

See #16198, you can't use development builds to test performance. We will be adding virtual scrolling to v-select in v3.1.0, follow #2660

[jaysonpotter]

That's fair @KaelWD, although it really is a HUGE contrast to what the development experience was like in v2. I also tried running this in preview and although it is better it still takes, as @mgrubb pointed out, almost 2 seconds for the selections to appear, and be selected.

Is running in preview a reasonable way to test performance?

[MtDalPizzol]

This is still a huge problem on supposedly "stable" 3.0.6.

I'm adding Vue Select to the codebase simply to be able to keep the project going until Vuetify reaches some sort of stability comparable to V2.

[mgrubb]

@MtDalPizzol I don't think that the devs, @KaelWD, think this is a significant enough problem to address, given the rather flippant initial response. With 39 items, I would expect this component to render nearly immediately regardless of prod/dev and without virtual scrolling. I've switched to quasar which has an almost identical api, and doesn't have this issue or the one with v-menu in #16104.

[MtDalPizzol]

@mgrubb I've been using Quasar since Vue 3 came out and Vuetify turned into this perpetual "soon" game. Quasar is good, but IMO, Vuetify is way better designed, from both aesthetic and dev experience stand points. I'm just sad that, at least at moment, this is sort of a Cyberpunk 2077 situation. It should had never been released and marked as stable at the current state, when even basic components are completely unusable. I'm trying to be positive about all this, hoping that at the end, V3 will be just as perfect as V2, but seeing the current pace, it seems to me that the next major Vue version be released and Vuetify will still be "alpha like". I understand that it's open source and free, but I also understand that it's the full time job for some authors and there's a company around the project and it's clear that they tried to bite a lot more than they could chew. I'm taking some time off Vue 3 after this experience.

[jaysonpotter]

I was also disappointed in the response from @KaelWD as well as not getting an answer to whether or not running in preview was a reasonable way to test performance.

I understand that virtual scrolling will be potentially added in March, which would significantly improve the rendering and interaction with the v-autocomplete component when rendering more than 50 items, but I felt sloughed off and that the time I put into preparing reproducible steps was not appreciated in the least. So although I felt good trying to contribute to the betterment of this great framework, I felt very much alienated.

I am going to treat this as an isolated incident and hope that @KaelWD considers making changes to how they interact with contributors.

[jaysonpotter]

Also just to note, I wasn’t able to report this issue till after converting a project from vue2 to vue3, subsequently vuetify2 to vuetify3, which included updating MANY other dependencies and bringing the code up to new standards.

The result of this was to revert everything. A couple weeks work became unusable because the interaction was unacceptable.

So the next time we evaluate updating our projects to vue3 the conversation might not be about updating vuetify, but what else should/could we use.

[jaysonpotter]

Tested this with the 3.1.0 release and same results.

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

[mavyfaby]

any updates on these?

[jaysonpotter]

Unfortunately not @mavyfaby.

[milospetkovic]

I'm also facing the same type of slowliness with vuetify version 3.5.1 and vue 3.4.0. v-autocomplete component has ~130 items to list, and dropdown opens in ~ 1 - 1.5seconds

[MtDalPizzol]

Hi folks... I suspect that this might have something to do with Vite. Here's the thing:

Vite uses chokidar to watch for file changes. The problem is that it only ignores the .git and node_modules directories by default.

So, if you're using Vuetify with Vite in an "uncommon" scenario, for instance, with Laravel, Vite will end up also watching all the files in the vendor directory, which will consume all your RAM and make your devserver REALLY slow, causing painful slow updates.

In my case HMR was taking up to 4s in some cases, and after configuring Vite to ignore the directories that didn't need watching, the HMR now takes about 10ms to 20ms, basically making things instantly.

I didn't tested it with Vuetify, but it might be that if you're in a scenario where Vite is watching tons of unnecessary files, it might be hurting the performance of your machine as whole, cause UI updates in the browser to perform poorly.

If you're willing to give it a try, you can ignore unnecessary directories from being watched using Vite's server.watch.ignored option.

server: {
    host: '0.0.0.0',
    port: 3000,
    hmr: {
      host: 'localhost',
      port: 3000
    },
    watch: {
      ignored: [
        '**/.devcontainer/**',
        '**/app/**',
        '**/bootstrap/**',
        '**/config/**',
        '**/database/**',
        '**/docker/**',
        '**/lang/**',
        '**/node_modules/**',
        '**/routes/**',
        '**/storage/**',
        '**/tests/**',
        '**/vendor/**'
      ]
    }
  },

[milospetkovic]

Hi @MtDalPizzol Seems like it's fast enough now. My current vite.config.js is:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
    plugins: [
        laravel({
            input: 'resources/js/app.js',
            refresh: true,
        }),
        vue({
            template: {
                transformAssetUrls: {
                    base: null,
                    includeAbsolute: false,
                },
            },
        }),
    ],
    server: {
        watch: {
            ignored: [
                '**/.devcontainer/**',
                '**/app/**',
                '**/bootstrap/**',
                '**/config/**',
                '**/database/**',
                '**/docker/**',
                '**/lang/**',
                '**/node_modules/**',
                '**/routes/**',
                '**/storage/**',
                '**/tests/**',
                '**/vendor/**'
            ]
        }
    },
});

I've added server property and it's fast. I'm using firefox on Ubuntu and it was very slow at the beginning. But, when I deleted browser's cache (which was more than 2GBs) it was fast enough under dev mode or vite. I'll continue with these options you've pointed out and see how it behaves. Thank you for the hint!