Closed Arooba-git closed 1 year ago
Name | Link |
---|---|
Latest commit | 6ace385cdb3aa151b943e3be4209245ef3251203 |
Latest deploy log | https://app.netlify.com/sites/evergreen-storybook/deploys/63cd0a33ca625c00086fe0ae |
Deploy Preview | https://deploy-preview-1598--evergreen-storybook.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Name | Link |
---|---|
Latest commit | 845b1f57b46cdd42ab5199f1d66861bbf6badcb5 |
Latest deploy log | https://app.netlify.com/sites/evergreen-storybook/deploys/63cd4c09c3f270000a62888b |
Deploy Preview | https://deploy-preview-1598--evergreen-storybook.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Overview Hello 👋 As part of our project, we are using Facebook's new Memlab tool to detect memory leaks in renowned SPA applications. While running the tool and analyzing the code of Evergreen, we saw that it does a very good job of ensuring that all async operations are cancelled when the component unmounts. However, as per Memlab execution results, we found that the cancellation of requestAnimationFrames is forgotten at certain places (TableVirtualBody being one of them) and was causing the memory to leak (screenshots below).
Screenshots [before]
Hence we added the fix by cancelling the frameRequest and you can see the heap size and # of leaks reducing noticeably:
You can test this and other potential leak sources, if you like, by running Memlab with a scenario file covering the maximum # of use cases. Following is a sample of the scenario file we used: evergreen-scenario-memlab.txt
Note that some other reported leaks originate from the Storybook library, hence ignored.