Vuetify: [Bug Report] high performance impact when using a lot of v-text-field
Versions and Environment
Vuetify: 1.4.2
Vue: 2.5.22
Browsers: Google Chrome
OS: Mac OS 10.13.6
Steps to reproduce
just input one char in one of the field while doing performance recording in chrome devtools.
Mesurement 1: with the exact codepen
Mesurement 2: removing all text-field except one
Mesurement 3 only one text-field but with @input="(value)=>this.field1=value" (for having just one half of the v-model behaviour)
Mesurement 4: with the 20 text-field replaced by standard input
Expected Behavior
Only have one text-field updated on each keypress.
Actual Behavior
Mesurement 1: 21,54ms
Mesurement 2: 2,98ms
Mesurement 3: 0,98ms
Mesurement 4: 1,94ms
Reproduction Link
https://codepen.io/stygmate/pen/zyVagj
Other comments
I test here with only 20 text-field but in my app i have 20 text-field by people concerned by the form and the mesurement are done on a macbook pro 2018. On my phone huawei p9lite typing on keyboard in a field can lag a lot.
stygmate
All 65 comments
mesurement 1
mesurement 2
mesurement 3
mesurement 4
stygmate
on 18 Jan 2019
I have noticed this in the past as well with many v-select elements, even when they all had the same items value. I worked around it for now but I figured I'd leave this comment here in case someone want to take a look at optimizations.
DRoet
on 18 Jan 2019
Any news on this? It really blocks my app development as I don鈥檛 know if I can rely on classic usage of v-model.
stygmate
on 21 Jan 2019
I also encountered performance problems when using many v-selects.
StefanFeederle
on 22 Jan 2019
maybe related to vue: https://github.com/vuejs/vue/issues/6898
will not be fixed until vue 3... any workaround ?
stygmate
on 23 Jan 2019
We have to found a workaround. it make Vuetify useless in case of consequent forms usage by lambda people. we are developer and many of us have decent computer but it's not always the case for most users.
stygmate
on 23 Jan 2019
Yeah seems like an upstream vue issue, tracked in https://github.com/vuejs/vue/issues/6351. I guess we will have to wait untill 3.0 : /
DRoet
on 23 Jan 2019
@MajesticPotatoe Hi ! why removing "critical" tag ? It's a Vuetify usage breaker for big form ! In my case the front as to be used by any surfer with any computer / phone configuration and the laggy input due to this bug are so bad that it will let the users with the filling of no confidence in the service.
if no one resolve this i have two choices: resolve the problem myself (unknown time of work) / pay some of you to work on a workaround for it to work with the actual vue version ... :(
stygmate
on 23 Jan 2019
It might be a good idea to at least keep it pinned. That way us developers can become aware of the issue if they encounter it and help encourage a resolution.
MatthewAry
on 23 Jan 2019
@stygmate mis-click, fat fingers.
MajesticPotatoe
on 23 Jan 2019
https://github.com/vuejs/vue/issues/5155 I think this bug has already been discovered a while ago. I don't think we will be seeing a fix in Vue 2 as they are declaring it as expected behavior.
MatthewAry
on 23 Jan 2019
@MatthewAry so i think the correct way to react is to code a WorkAround 馃挕
Discovering that i can't release to production a full App because of that is weird.
we can't wait 6/12/18/... months for vue 3 to maybe correct that.
stygmate
on 23 Jan 2019
Inputs are being updated as part of v2.0 and I will be looking to see if there are things we can do to alleviate this burden. Thank you for your patience.
johnleider
on 23 Jan 2019
@johnleider seems that Vue 2.6beta2 can adress our issue.
https://github.com/vuejs/vue/pull/9371#issue-247798326
But it may need some change in Vuetify code. Can you easily make all slots become scoped slot and using new v-slot syntax ?
I let you read the comment on the vue merge.
stygmate
on 27 Jan 2019
@stygmate John pretty much said on discord that if the changes in 2.6 are significant enough, they might take some parts of the framework and convert them to the new slot syntax for a 1.6 release
DRoet
on 27 Jan 2019
@DRoet I hope that this update will arrive as soon as possible. It would be like a Christmas gift that will (partially) deliver me from the pressure that I have for the release of my app. And anyway it will make the scaling capacity of Vuetify better for everyone / every project.
stygmate
on 27 Jan 2019
@johnleider hi, considering the recents change in vue 2.6 (new v-slot), can this issue be moved to 1.6 milestone ?
stygmate
on 11 Feb 2019
@johnleider Is there a workaround for this in the meantime? I have an app that is heavily form based and one of my forms has approximately 100 fields and performance is extremely laggy. Validation is handled server-side.
anaxmedia
on 17 Mar 2019
@johnleider any news ?
stygmate
on 21 Mar 2019
@MajesticPotatoe @DRoet @StefanFeederle @MatthewAry @anaxmedia @sh7dm Problem still here 2 months later in Vuetify 1.5.7 with Vue 2.6.10. Please @johnleider can you take some time to check if it can be resolved easily now, at least wrote to us a little message to let us know the evolution.
stygmate
on 22 Mar 2019
Hey everyone, I am tracking the issue. This is an on-going effort that primarily depends upon an upstream change. The 2.6 release of Vue has little effect on this particular component as we aren't even using slots except for labels.
I tested a few things to see how performance was and it is bad, but, unless one of you has a workaround, this will have to wait for changes from Vue as I'm out of ideas..
johnleider
on 1 Apr 2019
@johnleider thanks John , we appreciate the communication. Is there anything we can provide the Vue team? Do we know if this is something that they are tracking/working on, or even know is a performance problem?
Also, if this is an upstream issue, does that mean we will continue to see the same performance degradation in Vuetify 2.0?
anaxmedia
on 1 Apr 2019
My application used more than 50 <v-text-field>, and the same problem occurred.
(It's very very heavy :sob:)
So, I tried using :value="" binding and @change="" event instead of v-model="", the performance became some practical.
<v-text-field
:value="foo.bar"
@change="v => foo.bar = v"
></v-text-field>
dojyorin
on 10 Apr 2019
Why does the @change event perform so much better?
internalfx
on 11 Apr 2019
Because it's not triggered on every key stroke
jacekkarczmarczyk
on 11 Apr 2019
Why does the
@changeevent perform so much better?
Because it's not triggered on every key stroke
Yes.
In the case of @input, a slow task runs with each key input, but with @change, it runs only when the focus is out, so stress at key input is reduced.
However, as the problem has not been solved, there is a demerit that it will lag for a moment when the focus goes out.
In other words, it means first aid. :thinking:
dojyorin
on 11 Apr 2019
Looking forward for this problem to be solved :( until now I though it's only my issue, so a little google and I found out this.
My solution at this time for me is just to use @change but many times I need the @input but :( have to wait.
Will be watching this for updates.
Cheers
besnikh
on 14 Apr 2019
As we need help to resolve this, can someone of the crew pin this issue on Dashboard ?
It seems we are a lot to be affected without knowing if it's our code or Vuetify's code (my case before writting this issue, case of besnikh).
stygmate
on 15 Apr 2019
@stygmate I agree
In my case, my web app is published in production, and I have been receiving some complains from people that the app is running slow, me knowing the issue I am blaming their Samsung phone :)
I tested several times, and that's true though.. this issue is more obvious when used in mobile for Android devices.
But, would gladly help to fix this issue but not sure as you mentioned where to start, Vueitfiy is saying it's not their code but how Vue works.. so not sure.
Cheers
besnikh
on 16 Apr 2019
But, would gladly help to fix this issue but not sure as you mentioned where to start, Vueitfiy is saying it's not their code but how Vue works.. so not sure.
@besnikh it seems a problem with how vue handle slots. in some case (ours) when vue refresh a slot it refresh parents component and then parents and ... 馃槰
v-text-field is based on v-input and use slots for all it's sub-components.
excuse me for the short explaination (i don't have time now) but you can found some hints in linked issues.
stygmate
on 16 Apr 2019
@besnikh @johnleider i have relaunched the discuss at: https://github.com/vuejs/vue/issues/6351#issuecomment-485232248
stygmate
on 21 Apr 2019
@johnleider It seems this issue will not be resolved before version 3 of Vue ...
Is it difficult to write flattened version of v-text-field / v-select /... not based upon v-input ?
or some kind of precompilation of v-input based components for avoiding using slots ?
stygmate
on 22 Apr 2019
I was wrong about the slots thing, it's https://github.com/vuejs/vue/issues/7257 and https://github.com/vuejs/vue/issues/10115 combined with a very large render function. We may be able to improve this by caching as much as possible, but vue is still going to diff the DOM every time the parent updates.
Workaround is to create a <my-text-field> component that explicitly passes down everything you want to use without $attrs or $listeners.
KaelWD
on 7 Jun 2019
i use a single page form, users want to see all fields on same page without paginating.
i was having problems with text input lag as described here so i thought i would provide my real world example.
using all v-models
big oof ~150ms per keypress
https://codepen.io/anon/pen/QXpqZG = https://i.imgur.com/8n3pmi4.png
using all :value and @change
keypress not laggy anymore yay ~5ms per keypress
https://codepen.io/anon/pen/pXedPL = https://i.imgur.com/GlVDBeg.png
1010101110
on 21 Jun 2019
@stygmate
i made a example below to demo how slow when we want to click on checkbox :
https://codepen.io/hereiscasio/pen/MMQLwv?&editable=true&editors=101
it so slow that . . . do u know what happened when we click on it ?
why it so slow ? i think my demo related this issue u opened for ?
hereiscasio
on 1 Jul 2019
@stygmate
i made a example below to demo how slow when we want to click on checkbox :
https://codepen.io/hereiscasio/pen/MMQLwv?&editable=true&editors=101
it so slow that . . . do u know what happened when we click on it ?
why it so slow ? i think my demo related this issue u opened for ?
@hereiscasio It don't seem to be related to this issue. After a very quick look at it: I think you ask for displaying too much img at the same time.
stygmate
on 1 Jul 2019
@stygmate
i made a example below to demo how slow when we want to click on checkbox :
https://codepen.io/hereiscasio/pen/MMQLwv?&editable=true&editors=101
it so slow that . . . do u know what happened when we click on it ?
why it so slow ? i think my demo related this issue u opened for ?@hereiscasio It don't seem to be related to this issue. After a very quick look at it: I think you ask for displaying too much img at the same time.
yes, there're two issues there, what i point out is the later one, after u success to open dialog, u can try to check on checkbox, and u will see what happen,
( and actually, if u remove all image, issues still there )
Don't u think "use too many v-text-field" & "use too many v-checkbox" are the related issue ?
So did u mean u actually don't know what happen once i check on checkbox ?
I'm really interest about this, but just don't get the idea what happen
hereiscasio
on 1 Jul 2019
if you take out the v-model the checkbox click works correctly. so yes i think it is the same.
(the overall page performance is still slow by loading so many list tiles instead of paginating.)
`
Most helpful comment
My application used more than 50
<v-text-field>, and the same problem occurred.(It's very very heavy :sob:)
So, I tried using
:value=""binding and@change=""event instead ofv-model="", the performance became some practical.