fresco

Assuming you don't do heavy work in the UI-loop: I find react-native's bridge memory-management on Android rather questionable: [0] They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/ Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1] The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation. But: At least some guy or girl didn't ha

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 coll

I analysed react-native's performance issues with images and out-of-memory-errors a while back. Their (and their image library Fresco's) problem is that they make heavy use of object-finalizers, which is an error in Java and especially Android. I reported a couple of bugs, but got dismissed: https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8780 https://github.com/facebook/fresco/issues/1363 I found this rather frustrating. I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C. Again, a bugreport, again, dismissed. https://github.com/facebook/react-native/issues/10504 It seems that Facebook's Java programmers don't know Java very well.

Not sure if this is the right place, but I'll ask anyway. I recently reported bugs ([0], [1]) with Facebook's Fresco and React-Native about how their usage of Object.finalize() in critical places hurts GC-performance on Android/Java. I was asked to to show how getting rid Object.finalize() actually improves performance and memory-use. Apart from a simplistic profile [2], I don't really know how to show something like that. I'm still convinced it would be good if this got fixed. [0] https://github.com/facebook/fresco/issues/1363 [1] https://github.com/facebook/react-native/issues/8780 [2] https://github.com/facebook/react-native/issues/8780#issuecomment-243705273

I recently had a little feud with the developers of react-native and fresco (the Facebook image loading library) because of their extensive use of Finalizers: https://github.com/facebook/fresco/issues/1363 https://github.com/facebook/react-native/issues/8780 Apart from being unreliable, bad design, it slows GC and instantiation by orders of magnitude, which I considered important, but they did not. I added a comment about how uninstalling the Facebook app improves the battery life of a phone dramatically, that I deleted afterwards because it was too flamy. I don't expect this to get fixed ever :(.

Facebook using java.util.concurrent.Future<T> interface for downloading task: see here https://github.com/facebook/fresco/blob/c5e1d4cf2c081bf871f5... you can ether call future.cancel() or cancel(true): in first case download task will be finished but further processing in pipeline will be stopped. Future.cancel(true) is more aggressive and abandons download but you will get InterruptedException. As you see from source code Facebook using less aggressive approach with future.cancel(false) call.

The mandatory link to Facebook's stance on patents that make their "open source" a no-go for many: https://github.com/facebook/fresco/blob/master/PATENTS

Better: https://github.com/facebook/fresco http://frescolib.org/