Is Compose prone to problems similar to which a de...

# compose

[Sergey Y.]

Is Compose prone to problems similar to which a deeply nested Android ViewGroup suffers? I mean double layout taxation, slow measure/layout phases, etc.
On Android, we always tried to build a flat view hierarchy, without deep nesting or weights.
And what with Compose?

[Zach Klippenstein (he/him) [MOD]]

Compose’s layout system forbids double layout passes, so it’s specifically designed to avoid that particular problem.

[Zach Klippenstein (he/him) [MOD]]

A slow layout is going to be slow no matter what, so if you have a really complex ConstraintLayout, it will be slower than a simple Row. That said, there’s been lots of talk about shoving some Composition work onto background threads, which might mitigate that problem (it’s not been super clear exactly what that will look like yet).

[Zach Klippenstein (he/him) [MOD]]

Some more discussion about layout performance here: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1594751832267800?thread_ts=1594598732.179100&cid=CJLTWPH7S

[Sergey Y.]

Wow, great news. Thanks.

[Sergey Y.]

Does Compose could inline or merge some view constructions to a single layout? For instance, a text and an icon?

[Sergey Y.]

Or I think it doesn't make any sense because Compose already is drawing on Canvas.

[Zach Klippenstein (he/him) [MOD]]

There are semantics operators to let you group the sets of layouts that accessibility tools like TalkBack see, but I don’t think that’s what you’re asking. Compose won’t merge layouts, but it shouldn’t need to. If nothing in a Composable changed, and it doesn’t need to be re-measured, then it shouldn’t be re-composed (or re-measured, or re-layed-out, or re-drawn, etc).

[Sergey Y.]

lovely

[romainguy]

@Sergey Y. The existing View system draws on Canvas too

[romainguy]

That’s not relevant to merging

[Sergey Y.]

Well I mean the measuring

[romainguy]

Anyway on your original question:

[romainguy]

Yes Compose will prevent layouts that work in multiple passes

[romainguy]

but

[romainguy]

Deep nesting means deeper call stacks, more code to execute, more state to track, potentially more complex drawing trees, more allocations, etc.

[romainguy]

No matter what, doing less is always going to beat doing more 🙂

[romainguy]

So: profile your app

[romainguy]

If it’s too slow, optimize it, otherwise you’re good 🙂

[Leland Richardson [G]]

lol. finally, i have the answer to all of my performance woes 🙂

[Sergey Y.]

So: profile your app

and keep calm. Yes, I know Colt's tagline 🙂
#perfmatters

[romainguy]

@Leland Richardson [G] Performance work is pretty easy turns out, just make slow things fast!

[Leland Richardson [G]]

As @Chuck Jazdzewski [G] once told me, all performance improvements end up boiling down to one of:
1. do less work
2. do work less often
3. use information you weren’t using before

[Leland Richardson [G]]

OK, I think we’ve sufficiently derailed this thread now…

[Chuck Jazdzewski [G]]

The actual quote is,
1. do less
2. do it less often
3. do it some other time

[Chuck Jazdzewski [G]]

The "use information you weren't using before" helps with the above.

[Leland Richardson [G]]

ah, i knew i was gonna mess it up

[Leland Richardson [G]]

this is why we have you do the perf work

[Chuck Jazdzewski [G]]

You can still do 2/3 of the perf work...

[romainguy]

Taking notes…

[curioustechizen]

Why is this gem of a discussion hidden inside a slack thread? Why? I demand it be spun out into a Twitter thread or something. Especially those quotes 😛