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 leak with VelocityJS v1 #1486

Open
micaww opened this issue Oct 24, 2019 · 0 comments
Open

Memory leak with VelocityJS v1 #1486

micaww opened this issue Oct 24, 2019 · 0 comments

Comments

@micaww
Copy link

micaww commented Oct 24, 2019

Description

VelocityJS v1 has a bug that causes it to hold references to elements even after they have been removed from the DOM and animations are finished. This causes elements in a Kiln edit overlay to never get garbage collected, including their entire Vue component tree, resulting in tons of memory being added to the heap without ever getting cleaned up. For some of our more complex editable components, we've measured upwards of 1 GB of memory being retained over time on a single page.

Here is a related bug report from 2017 on VelocityJS v1 repo, in which a collaborator suggests to upgrade to the v2 rewrite: julianshapiro/velocity#760

To further prove that Velocity is the sole cause of this issue, I've made a hacky fork of Kiln that removes the Velocity dependency and animations altogether: https://github.com/micaww/clay-kiln/tree/no-animations. The heap never grows beyond the size at initial page load without getting correctly garbage collected.

A suggested fix for this would be to either upgrade to Velocity v2, which might still be in beta, or to find another way to handle animations without using Velocity v1.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Load any page in edit mode
  2. Open Chrome DevTools to the Memory tab
  3. Click on the "Garbage Collect" (trash can) button to ensure clean slate
  4. Take a heap snapshot
  5. Open and close a component's edit mode until the current heap size is noticeably increased
  6. Click on the "Garbage Collect" button again and observe that some memory is not being freed
  7. Take another heap snapshot
  8. Inspect the snapshot and find the largest "Retained Size" element
  9. Click on it and go to the Retained table at the bottom. It will lead to a Velocity retainer via stack trace

Expected Behavior

Memory allocated in order to show a component's edit overlay should be properly freed when the edit overlay is dismissed (or on next GC pass)

Screenshots

Before and after heap snapshots:
Screen Shot 2019-10-24 at 12 44 01 PM

Shows retained elements after opening and closing a single component 5 times.
Screen Shot 2019-10-24 at 12 45 46 PM

Note: a in the screenshot is an instance of VueComponent. It's just minified here. 152 MB (top right) is used up by these components and never freed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant