Potential memory leak when hiding components early.
See original GitHub issueDescribe the bug
When toggling the visibility of some quasar component’s parent just after/while they are rendered, we see that the memory used by said component is not freed after un-render. This seems to be affecting at least q-menu and q-img and especially when they are rendered under “keep-alive”, but might affect more components/scenarios.
Codepen/jsFiddle/Codesandbox (required or your issue may be closed) Sorry, I’m not sure a live environment is very practical to measure the memory difference as outside factors could make the measurement difficult. I have set up this repository that should be able to show some of the problems, so I hope this would be acceptable: https://github.com/CamilleDrapier/quasar-test
There are multiple branches:
- with “q-menu”:
keep-alive-menu
seems to have a memory leak problemv-show-menu
, is a variation of the previous one and does not show memory problem as far as I know
- with “q-img”:
keep-alive-img
seems to have a memory leak problemv-show-img
, is a variation of the previous one and also seems to have a memory leak problemq-img
, is a simpler variation of the previous one and also seems to have a memory leak problem. In this case, on Firefox, the memory problem seem to be harder to detect as sometimes a “Cycle Collection” would happen, but on Chrome we can observe a constant increase in the application footprint as we click on “toggle”.
To Reproduce Steps to reproduce the behavior:
- Run
quasar build; quasar serve -p 8081 dist/spa/
- Access http://localhost:8081 with your favorite browser (preferably in private windows mode, so that extensions do not interfere with measurements)
- Open the “Developer tools” of your browser on the “memory tab”
- Click on the “garbage collector button” (Chrome) or the ‘GC’ button on the
about:memory
page (Firefox) - Record the initial memory (snapshot)
- Click on the “toggle” button 10 times
- Click on the “garbage collector button” (Chrome) or the ‘GC’ button on the
about:memory
page (Firefox) - Record the memory again (snapshot)
- (Edit) Repeat steps 6,7,8 again multiple times
Expected behavior The memory used by the application does not increase consistently each cycle of toggling the content on and off.
Screenshots
For example on the keep-alive-menu
here is a view of the memory increase for multiple batches of 10 toggles.
Platform (please complete the following information): Quasar Version: 2.4.2 @quasar/app Version: 3.2.6
Quasar mode:
- SPA
- SSR
- PWA
- Electron
- Cordova
- Capacitor
- BEX
- Vite Plugin
Additional Info:
- Typescript
- SFC usage with
<script setup>
- Vuex
- Prettier (eslint)
- Standard (eslint)
Tested on:
- SPA
- SSR
- PWA
- Electron
- Cordova
- Capacitor
- BEX
OS: Linux (20.04.2-Ubuntu SMP) Node: v16.13.1 NPM: 8.1.2 Yarn: Browsers: Firefox/Chrome iOS: Android: Electron:
Additional context
While upgrading our application from Quasar1 to Quasar2, we noticed a sizable increase in the memory footprint of some of our pages, especially for one page that displays a list of components: for each component (that is quite complex/deep) we determine after it is rendered (in our application it is on some “intersection event”, but is this app I have simplified this to “mounted” for a similar result memory-wise) if it should be kept visible or not, if not we store its size and set that size to a dummy container and “unshow” the content. This seemed to be working fine in quasar1, but is problematic in the newest version.
If this sort of thing is something we should avoid doing at all in Q2/vue3, is there some documentation that could help us know this? Or is there a better way to achieve this behavior?
Thanks a lot for the work on quasar in general and on the Quasar2 in particular!
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (6 by maintainers)
Top GitHub Comments
Thank you for the comment above. Hope that the Vue hook will be fixed soon. Would you be so kind to drop a message here when it does, so that others that read this ticket also know?
The “loading” prop is assigned as an attribute to the native rendered image. So if I understood correctly and there’s a memory leak by using it then it means the browser itself is at fault because it does not releases the memory when the native img is removed from DOM. So not sure how any framework can help because it’s not their fault (Quasar or Vue).
In any case, until this is fixed in browser(s), you can use
loading="eager"
.