Being able to reply like that is priceless, though

Hey Jorge, I was looking at a trace today and I wondered... In android compose, does it make sense to render the view ahead of time, as a parallel to asynchronous inflation? Let's say I keep the compose root hidden until the network data arrives. Does compose reuse views internally on android?

Halo

Damn. Not KMP too.

... You can deal with the data in the same fashion you do now, have react read it from native, as a prop (stateless function parameter in compose). Then you can compare against a stateless compose version

It does not really make sense to go from compose to react. Compose fixes stuff affecting react, and kotlin allows to truly separate declarative UI code from everything else. So it will feel weird. Maybe try adding a RN screen/component to a compose app...

I would argue we had all that, even without Rx. The difference is, you don't need much effort to pick up coroutines, and that's their biggest selling point. JVM concurrency is powerful, but it does need lots of practice.

If Compose Multiplatform is drawing directly on iOs (like, through Core Graphics or similar), it would be more reliable, since the output would be pretty much guaranteed. If it is just repurposing SwiftUI/UIKit underneath, it would be as reliable as RN, perhaps more given the shared memory access

You live the life made for you by the person you were 10 years ago. And there is a moment when you need to invest in things that aren't your career. Nobody gets younger while time passes.

Damn that's me.

But I'd like to point out, we were using regular java libraries. It was super fun to see your code explode after swapping out from Ant to Maven.

But it was fun.

The saddest part is, that actually happens sometimes

"ship it, ship it, ship it" oriented development.

The baeldung blog would be a good starting point, it is very approachable, then you move into books and documentation.

The CPU profiler, The Debug class traces and custom markers are the best way to diagnose this. I'll try to take a look.

... It means your tasks are too serialized, forcing the app to wait all the time. Like a McDonalds with 10 doors and 1 cashier. Usually this points to the amount of JS callbacks. No matter the architecture, if you are running a callback from native, the others are not running.

The CPU type can play a role too. An A12 has a 4+4 CPU. Android reduces both frequency and amount of awoke cores to save up energy. So, CPUs with multicore clusters tend to underperform with single thread tasks. Try a 1+3+4 or similar CPU. If the results are super different...

Native operations need to delegate the actual work to dedicated threadpools, and leave the module thread alone. That makes a huge difference.

You also need to consider the type of operation you are waiting for. If you are using the keystore for example, that adds a ton of time.

Do you have a specific feed to reproduce? For this kind of issue, the dataset is critical.

There are a ton of things to look for here.

I would start by profiling the CPU activity and check how optimal the associated native operations are.

Everything eats CPU time. You need to balance the workload to ensure background work can't take over the entire CPU, and balance the background workload so no single work lane takes over the entire CPU portion dedicated to background work