Is recompose kinda like invalidate?

# compose

[andrew]

Is recompose kinda like invalidate?

[Leland Richardson [G]]

do you mean the Recompose component?

[Mihai Hrincescu]

@Leland Richardson [G] Seems that re-composition is run inside the animation callback and is all done on the main thread. Are there plans to move this to a different thread?

[Leland Richardson [G]]

Yes. Compose has been designed to be able to have composition run on any thread, and even potentially with parts of the tree in parallel. We are still working out some of the details here though, and we will have to see what types of strategies work best

[Leland Richardson [G]]

in other words, right now everything is running in a single threaded fashion, but it likely will not stay that way, and things like @Model and @Composable have been designed intentionally to support some different threading strategies, but we haven’t been able to test them out yet due to some limitations of the IR kotlin compiler until recently

[Leland Richardson [G]]

we’ll talk more about threading strategies once we have a better picture of what works and what doesn’t, since we haven’t experimented enough yet

[Mihai Hrincescu]

That is great news, there should be some great performance gains once that work is moved off the main thread and inline classes are here.

[Leland Richardson [G]]

yep, that’s our hope! 🙂

[Mihai Hrincescu]

Is a lot faster to get an UI up with compose but the longer frame times kinda kept me away from experimenting with it. And i couldn't see what was taking so long since compose traces do not show up systrace. (Edit: turns out they do show up but they are in the app space, and i was taking the trace wrong).

[Leland Richardson [G]]

yeah, definitely

[Leland Richardson [G]]

performance is really important to us, but a lot of things on the compiler side were really about getting things “working” and “correct” first, so that the broader team could iterate on making the toolkit. We are starting to be able to implement some of the optimizations we have been planning for quite some time, and reap the benefit. there is still a lot of low hanging fruit

[Leland Richardson [G]]

we have a lot of benchmarks that we are tracking, and will be adding more, but where we are right now is definitely a lot slower than where (i think) we will end up

[Mihai Hrincescu]

Like you said "not production ready yet". I was also looking at Litho and the performance they get is incredible and i don't see any reasons why Compose couldn't match or beat that. Anyway great job until now , I'm looking forward to using it in production.

[Mihai Hrincescu]

Also is there something like a coroutine effect?

[jim]

@Mihai Hrincescu With regards to performance, yes, that is our hope too. We've been careful about our design decisions to avoid cutting off future paths of optimization.

[jim]

With regards to coroutine effects, not yet, but we plan to add them. The biggest issue is that the IR has not had any support for coroutines until very recently, and Compose depends on the new IR backend, which prevents us from using coroutines. We look forward being able to build APIs that use coroutines very soon.

[Mihai Hrincescu]

@jim That is great news. Can't wait for the next releases and some more documentation about it. I found @Leland Richardson [G] talk really enlightening about the inner workings.