-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Potential memory leak in computed #9233
Comments
This is not a memory leak. core/packages/reactivity/src/computed.ts Line 59 in b8fc18c
|
like @Alfred-Skyblue said above. this is not a memory leak. |
@Alfred-Skyblue I see, I guess that makes sense from a technical perspective. I'm not sure it's great from an API usage point of view, but I also don't see how to easily improve that. @edison1105 I had vue-devtools turned off. |
I modified your minimal reproduction to highlight the more obvious problem: computed cannot be recycled when it is no longer referenced |
@johnsoncodehk If we want to solve this problem, we must run the |
@Alfred-Skyblue I don't think the author's original problem needs fixing, it's expected behavior, but my playground link shows a different problem, someObject still doesn't get recycled even though computed itself is set to undefined. |
I dug a bit more and it seems the case @johnsoncodehk discovered is an edge case.
I'd argue the 2nd case is far more common (and probably 99.9% of the case) in real world apps. I've never seen anyone manually setting computed to |
Closing as the original issue is not considered a leak: a leak means the memory has a chance of infinitely growing over time - in this case, there will always only be at most 1 copy of a cached value held, and it is properly released on next access / component unmount. |
Vue version
3.3.4 (all 3.* versions I tested this with were affected)
Link to minimal reproduction
https://play.vuejs.org/#eNqdVMFu2zAM/RXBpxRI7EN3ypKg29AB7aEd2l0G+KLYdKJWlgyJTpoF/vdRkp0oSTsM66Wx+PT4+ERyn3xpmnTTQjJNZrYwokFmAdtmkStRN9og27NC102LUI6ZgWrMthyL9W1VQYGsY5XRNcsTosiTXOWq0MoSh67hcflCkG8SuIGSzd3lUcWlhasBVVBMtQ3FFGzZd6G4FL85Cq2eYCUsmt3oFXZsvmB7okZRsfA9n1PGY4o8uQqAHB2vlpBKvRrFEJ+KZBA0AC8EphsuWyApaKgUwnS56hxYSYjreYKqr0W1Uh5Kifh6twg1GDcaXbkiTkhCPp8gMPCiAGvpVgDHldw/Pz6kZIdQK1HtRpe5erKIzdd7IPPuvJPeOU9VuOhHzrl6t9yeGEjWDHmEEvh8tPkkYZbFvdKbMET+u0C63F19HiTHzlP2PUN4wym1xxqk1GyrjSTNzCn+wICojxxnaMnU+AYEE2kZnzedN+LUgBEdzrIwSDRC9IFQN5Ij0NfMTVWOdxXb6ZZVwpD6xrhHz5Pw+qSUq5LhGhSdecvzZByXKCzNygbM8B6pY/xFdGu+AYa6J+ybia+4UO40tIPAdLY0TknmpPR6ZssWUSt2U0hRvM6PWhbhxywLgPfBvciF/38C3e/pOS4XQce6jrGDhuxgUDJO0NKbVmKVvlitaCVRsxA0cXMkJJjHxu0GUjZ1bcToj8TSM2/v/Zmb3PFwXqyheH3n/MW+ubM8+UFGgdnQ2jrEkJsV0Mu68O3zA3VSFKx12UpC/yX4BNTRrdMYYF9bVZLsCOfV3vnFSr3+096+ISg7FBVWD2Odx/ul6gbgo9KPcq/Ta3+POpJcDIt7UvPmzMcQOCXxi9sPDGJjp1lWlIqulSDFxqQKMFNNnd0QLDOtQlHDpNT1DWVMP2UlzUh8nIKtJ0ujt+QskUSFu/vebjMxoEowzpZ/S3t2LU59FrpIfzCl+wNg0WvC
Steps to reproduce
Click on "access" and then on "clear". Even if you then manually trigger garbage collection in the browser, "someObject" doesn't get removed from memory. You have to click "access" again for this to happen.
What is expected?
That after "clear" is called "someObject" gets garbage collected because there shouldn't be anything referencing it.
What is actually happening?
"someObject" stays in memory until the computed property is accessed again.
System Info
No response
Any additional comments?
This was the cause of a huge memory leak in my application that took me very long to discover.
The text was updated successfully, but these errors were encountered: