When I worked at Facebook, I worked on a web memory tracking tool I was particularly proud. It went through links, grabbed heap snapshots, diff'ed them, found objects that weren't cleaned up and gave detailed information about its retain chain. You can see a lighting talk I did on it at BlinkOn: https://www.youtube.com/watch?v=JuyaGFApifA&t=1427s&ab_chann...
Colleague of bgirard at Facebook here, we are planning to open source the tool in 2022. Great to find someone also working on memory tooling here :) Fuite seems really interesting, will try it out!
Author here. I wasn't aware of your talk, but it's super interesting! Showing info about the retain chain is a great idea, but I didn't get around to doing it in fuite. IME just counting the number of objects is actually pretty effective to find the smoking gun. (You leaked 1 event listener, which leaked a bazillion strings, arrays, objects, etc., but all you really care about is the 1 event listener.)
I would love to see how your tool approaches this! Hope it gets open-sourced. :)
Hi bgirard! I support the FB team that works on this - it's on the roadmap to open source hopefully H1 next year :) It's continued to find significant leaks in other parts of our infra too, so hopefully it will be equally helpful to others. Great to see others looking at memory tools now too - I'll definitely be checking Fuite out
Almost all SPAs do have memory leaks in my experience. I was once involved in Eclipse Memory Analyzer project(for Java, short MAT), and I mentored a student who built a prototype to support JS in MAT.
We easily found significant memory leaks everywhere. That prototype was never released for reasons I cannot comment on in public.
Serious question, is it really more difficult fir server side JS? At least you don't have to fiddle around with DOM references. The potential impact on the server side is of course potentially bigger.
I mean it depends on the application naturally, but flame graphs or no and especially when dealing with heap dump comparisons, sometimes very opaquely named symbols, etc, it can be an exercise in frustration.
Browsers - Chrome especially - have really fantastic tooling for doing stuff like this. I think there's some way to hook those up to Node, but they're very readily available on the front-end
You can use chrome's tooling directly from nodejs. You just need to invoke nodejs with `node --inspect` (or --inspect-brk to pause before the first line of code is executed). Then open chrome's dev tools. A nodejs icon will magically appear at the top left of the dev tools pane. If you click that it'll open a new window with chrome's debugger, profiler and memory tools working directly with nodejs's v8 instance.
This is actually really important. If you're a tab whore like me you'll always find a site that eventually eats up all your RAM and kills the browser dead. More SPAs need to test for memory "leaks" like these, especially if they're repeatedly creating large numbers of DOM elements through scripting.
Having to point at a URL and crawl for pages seems awkward. Is there something I can directly integrate into my app? How would it deal with a login page?
Ran into the same limitation. I had tried logging in to a local dev server and then running fuite, but it looks like it runs the tests in its own personal chromium instance so my session wasn't used.
There are no memory leaks on my login and sign up pages though!
edit: just checked the docs and it says you can specify a scenario script with a setup hook to get passed authentication.
This specific issue makes the "PHP way" (just to mention a notable example) of having an interpreter created to serve a page and then destroyed at the end, much more convenient, even if more resource intensive. Assuming the problem is not in the Javascript side of a single page application, of course.
How do crawler approaches like this handle SPAs that have a multi-step onboarding flow before getting into the actual heavy-hitting areas that need the most testing? (e.g. where you may have to click through several things before even hitting a route change)
Very cool. Looks extremely easy to use which is the difference between people using tools or just reading about them :)
As an aside, I created some tooling for identifying memory leaks in Python apps. Once I started sending the results to Slack and formatting them nicely, I found people ran the tool more frequently. Usability is everything.
This is a welcome surprise. I have been hunting down memory leak problems for a hardware installation that runs a JS heavy app 24/7. Had to build in auto software resets just to clean the garbage because there was no real solution. Looking forward trying this out asap
Great point! This is exactly why fuite does a preflight iteration before the "real" iterations. One-time setup costs shouldn't count against the "leak" – only sustained memory growth.
We used it to find a problem fixed in React 18 that caused large leaks on Facebook.com: https://github.com/facebook/react/pull/21039#issuecomment-80...
We also found one issue that caused a leak that's impossible to spot unless you know how V8 closures are implemented and retain one another.
I'm really hoping to see Facebook open source the tool some day!
Fuite seems really interesting. I like the idea of an automatic crawler!