Fix slowdowns when navigating

Continued from https://github.com/fsprojects/Fabulous/issues/373#issuecomment-480486017

I just tried the AllControls sample on my Android device (release mode) and WPF on my beefy desktop computer. There are fairly noticeable slowdowns when navigating on Android, and less so (sub-second, but still noticeable) on WPF. After a cold start on Android, navigating to TabbedPage 3 takes around 2 seconds. I have a hard time imagining clients/employers (or users) accepting that, regardless of maintenance/agility benefits of an Elmish architecture.

• What is the root cause of the navigation slowdown, particularly on Android?
• Which factors influence it? (Devices? Model size? etc.)
• Can anything be done about it? What?

[TimLariviere]

Does reflection slow down the performance?

Yes, reflection can slow down performance. But you will only notice performance issue if you make intensive use of it. Individually, it’s not that bad.

That’s why we tried to limit reflection to a minimum in Fabulous.XamarinForms.

The line you’re referencing is one of the few (if not the only one) to use reflection. So I don’t think it’s the source of the slowdowns…

Instead, I think we’re a bit too heavy on the memory. Every time I noticed slowdowns, a corresponding output in the console indicated the GC triggered. GC pauses the app for several milliseconds, enough to make it noticeable sometimes.

So we either don’t clean up enough memory, or we’re instantiating too many small objects that clutter up the memory forcing the garbage collector to pass.

This seems to fit because iOS is not plagued by those slowdowns, while Android takes it fully. On iOS, it’s fully native no GC (only reference counting) - on Android, there’s 2 of them (.NET GC and JVM GC)

[cmeeren]

Note that the AllControls app has not been performance optimized, i.e. there are relatively few dependsOn calls which are pretty much necessary to get good performance for incremental view update.

Does that explain the poor performance when navigating, but much better performance at the page after navigation?

A more general question is how we might best guide the user as to the best place to insert dependsOn calls.

For example, could there be a mode (or Debug mode) that reports when large parts of the View tree re being re-created (as objects) but are in fact identical (and perhaps even relate this to exact source line locations or stacks where the uppermost invariant ViewElements were created?)

I like the idea. The question is how to set the thresholds so the warnings are real and not spammy.

Also, I think clear documentation can get you far on its own. 😃

Note also I don’t think dependsOn is the only way to avoid recomputation of view sub-trees under invariant sub-models., it’s just one relatively simple way. I’d like to hear of other suggestions and hacks that do this.

Some kind of Key property might be good for collections. It would allow you to do smarter differential update of collections, regardless of element ordering. AFAIK it’s an important optimization in React (they throw warnings at you if you don’t supply it in collections), see the React docs on reconciliation. Not sure how easy it is though, given that you can add any attribute to any HTML DOM element, but here we are working with objects with a limited set of properties.