Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory not released when object is passed as prop in v-for loop #4738

Closed
kad-tijhuo opened this issue Oct 5, 2021 · 5 comments · Fixed by #4833
Closed

Memory not released when object is passed as prop in v-for loop #4738

kad-tijhuo opened this issue Oct 5, 2021 · 5 comments · Fixed by #4833
Labels
❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. 🐞 bug Something isn't working

Comments

@kad-tijhuo
Copy link

Version

3.2.19

Reproduction link

sfc.vuejs.org/

Steps to reproduce

  1. Create an array of objects
  2. Loop through the array with v-for and pass the current object as a prop to the child component
  3. Empty the array

See minimal reproduction:
Check chrome memory profiler. After forced garbage collection the Page class objects / children still remain in memory.

What is expected?

All children disappear and all the memory that was occupied by the objects inside the array is released.

What is actually happening?

The children disappear but the child instances are still in memory and holding on to the objects passed as props, not releasing the memory. This even happens when you don't do anything with the prop inside the child component, passing it in is enough to trigger the issue.


The issue seems to have been introduced in version 3.2.14. When I go back to 3.2.13 (tried 3.2.10 as well) the issue disappears and the memory is freed properly like expected.

@kad-tijhuo
Copy link
Author

Our use case is being able to switch between pdf's and looping through the pages to render them. Each page is a child component of the pdf viewer.

When switching between 4 pdf's, one after another and forcing garbage collection before taking the screenshots:

Vue 3.2.13 (expected, the last pdf was 20 pages long):
image

Vue 3.2.14+ (all previous pdf documents/pages are still in memory because the document and page are passed as props to the child components):
image

The only difference is the Vue version.

@posva posva added ❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. 🐞 bug Something isn't working labels Oct 5, 2021
@yyx990803
Copy link
Member

yyx990803 commented Oct 7, 2021

Interestingly this is caused by #4653, looking into it.

Update: can confirm this only happens in the dev build.

@yyx990803
Copy link
Member

yyx990803 commented Oct 7, 2021

/cc @Akryum this is caused by the devtools emit buffer holding references to component instances. When the browser has no devtools installed, the buffer is kept forever so the unmounted instances are never released. This can happen in production too if the user has PROD_DEVTOOLS enabled.

The late injection seems to only happen in iframes, but the tricky part is we can't easily tell whether devtools is simply not installed, or that it's just not-yet-injected.

@yyx990803
Copy link
Member

Ideally we want to know that there's just no devtools installed so it should not buffer anything. But the easy fix I can think of right now is a setTimeout to clear the buffer if the devtools is not injected after a certain period of time.

@kad-tijhuo
Copy link
Author

@yyx990803 Thank you for looking into this issue so quickly. Unfortunately the setTimeout fix doesn't seem to work. With Vue 3.2.20 memory still isn't released properly, even after waiting for a longer period than is set in setTimeout.

Both screenshots were after switching from a 123 page pdf to a 12 page pdf, waiting for a least 5 seconds, then forcing garbage collection.

Vue 3.2.13:
image

Vue 3.2.20:
image

@github-actions github-actions bot locked and limited conversation to collaborators Oct 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
❗ p4-important Priority 4: this fixes bugs that violate documented behavior, or significantly improves perf. 🐞 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants