Poor render performance with many QInput components
What happened?
Adding a lot of QInput components (In my case 500) to the page results to a huge lags.
I noticed that the wider the browser window, the more lags. Using profiling in DevTools shows that the browser is busy rendering most of the time.
What did you expect to happen?
No lags
Reproduction URL
https://stackblitz.com/edit/quasarframework-webpack-zkdeka?file=src%2Fpages%2FIndexPage.vue
How to reproduce?
- Go to reproduction URL
- Open demo page at new window, resize window to fullscreen
- Move mouse and see how it lagging
Flavour
Quasar CLI with Webpack (@quasar/cli | @quasar/app-webpack)
Areas
Components (quasar)
Platforms/Browsers
Chrome
Quasar info output
Operating System - Windows_NT(10.0.22621) - win32/x64
NodeJs - 18.12.1
Global packages
NPM - 9.2.0
yarn - 1.22.19
@quasar/cli - undefined
@quasar/icongenie - Not installed
cordova - Not installed
Important local packages
quasar - 2.12.1 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
@quasar/app-vite - 1.4.3 -- Quasar Framework App CLI with Vite
@quasar/extras - 1.16.4 -- Quasar Framework fonts, icons and animations
eslint-plugin-quasar - Not installed
vue - 3.3.4 -- The progressive JavaScript framework for building modern web UI.
vue-router - 4.2.2
pinia - 2.1.4 -- Intuitive, type safe and flexible Store for Vue
vuex - Not installed
vite - 2.9.16 -- Native-ESM powered web dev build tool
eslint - Not installed
electron - Not installed
electron-packager - Not installed
electron-builder - Not installed
register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
@capacitor/core - Not installed
@capacitor/cli - Not installed
@capacitor/android - Not installed
@capacitor/ios - Not installed
Quasar App Extensions
*None installed*
Networking
Host - VPC
Ethernet 2 - 192.168.1.10
VMware Network Adapter VMnet1 - 192.168.47.1
VMware Network Adapter VMnet8 - 192.168.134.1
Relevant log output
No response
Additional context
No response
Faced the same issue with button component.
I noticed a similar problem with a lot of q-input components on a page. To test it, I created a page with 5,000 (!) q-inputs. The heap size increased about 200M and the memory was not released when the page was unloaded. If I change the q-input to a regular input the page loads quickly and all memory is released properly. Is there a memory leak in q-input?
~Same issue here: #12369.~ nope, actually a different issue, but possibly related!
In my case, I'm seeing extremely slow rendering (a bit under 1 second) with just about 150 q-inputs (it's a list with 50 elements that have 3 q-inputs each). 1 second might not sound like much, but this happens when the user attempts to navigate to another page, so it's rather substantial. I can confirm that, at least in dev mode, unloading the page does not help, and with each remount, the page gets progressively slower, which is rather strange. Anyways, the quick remedy is this workaround, but it's rather unbelievable that q-input has to be so slow, so I hope there's going to be a fix for this.
A slightly different problem is described there. There the problem of the first rendering of elements is described. In my opinion, there is not really a quasar problem there, but vue itself. Itβs just that q-input consists of a large number of html nodes and adding them to the DOM takes a lot of time, I think.
The current issue describes the problem of constant lags on the page with many components (any action occurs with a strong delay, including simple hover around elements).
The first message contains a video demonstrating the problem.
Running into this issue as well on a page with many q-inputs. Every action taken on the page has lag.