[cel1ne]

Hi, astreet, thanks so much for taking your time,

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.

[astreet]

I see, if we're talking about apps somehow accumulating thousands of finalizer references, something seems very wrong, as we're talking about 10's of ms of work. I'm not sure how many references we typically hit in our apps, but I'm pushing the fresco team to A/B test with removing finalizers to actually see what impact we see in our apps: it'd be a good data point to have internally and externally about using finalizers. That being said, we're hoping to update the OSS RN version of fbjni which uses a PhantomReference queue, and Fresco has also been considering a PhantomReference queue. I'll try to keep you updated on the fresco task.

[cel1ne]

Splendid news, thank you.