|
|
|
|
|
|
by astreet
3427 days ago
|
|
|
Hey, RN Android dev here: re: object finalizers: - For Fresco, I think Balazs provided a pretty good response here on how Fresco uses the finalizers (https://github.com/facebook/react-native/issues/8711#issueco...). If you still think there's an issue here, I'll direct Balazs to this post.
- For RN, I remember the issue you cited stated that using Object.finalize is 430x slower than having no finalizer, which sounds really bad until you realize we're talking about 430x slower than 5.6ns. Even though we may create thousands of these objects during a typical startup, this cost adds up to a couple of ms across startup -- since we had other ideas for more impactful perf improvement, we didn't take this on, especially since the proposed alternative at the time was to but the onus on developers to remember to manually free these objects. That being said, we've switch to using PhantomReferences internally at FB for this (which is strikes us as a better solution than either of the above), and hopefully will sync that with open source soon. Re: bridge serialization, I'm sorry that issue fell through the cracks, I'll make sure that we follow up on it internally. I think there's a meta-issue around communication here on issues and PRs, and while there are a ton to follow up on every day, the RN team could be doing better following up on the important ones that need addressing from the team (I think the bridge serialization issue qualifies), and setting proper expectations on all others. I'll follow up on that internally as well. I apologize on behalf of the team that it's been frustrating -- I promise we do appreciate all the help we get from the community and try to balance working on our internal goals and with the community as best as possible. |
|
|
I want to stress again that finalizers complicate and slows code in very complex ways. Just measuring the startup time isn't enough. You essentially slow down the garbage collector by giving him work and code he can't analyse or optimise.
The mere usage of finalizers, even if they log only, can lead to Out-Of-Memory-errors when there's still memory available!
This user showed that the numbers of waiting finalizers went up to a couple of thousand after they switching to Fresco: https://github.com/facebook/fresco/issues/1363#issuecomment-...
Think about it: 5000 finalizers waiting to be run! The finalizer-queue is single-threaded, which means that every other object on the same ART that has a finalizer will have to wait until these 5000 finalizers are through, before they can be garbage collected.
No need to apologize though, I know that RN is being flooded with attention and changing core code is not trivial.
Again, thank you for your time.