Thread
#compose
    andrew

    andrew

    2 years ago
    Is recompose kinda like invalidate?
    l

    Leland Richardson [G]

    2 years ago
    do you mean the Recompose component?
    m

    Mihai Hrincescu

    2 years ago
    @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?
    l

    Leland Richardson [G]

    2 years ago
    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
    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
    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
    m

    Mihai Hrincescu

    2 years ago
    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.
    l

    Leland Richardson [G]

    2 years ago
    yep, that’s our hope! 🙂
    m

    Mihai Hrincescu

    2 years ago
    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).
    l

    Leland Richardson [G]

    2 years ago
    yeah, definitely
    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
    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
    m

    Mihai Hrincescu

    2 years ago
    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.
    Also is there something like a
    coroutine
    effect?
    jim

    jim

    2 years ago
    @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.
    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.
    m

    Mihai Hrincescu

    2 years ago
    @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.