Do we have to write

inline

to inline lambdas in a function marked with

@Composable

or does the annotation processor optimize it for you?

Question is whether it should even be inlined. It might result in huge functions.

Inline composables will be supported but they will require the keyword just like normal functions.

@Leland Richardson [G] Instead of inlining the whole function, inlining only its lambda. Example: In the following example, we would not want all of

withPrideHeaderAndFooter

to be inlined at call site.

@Composable inline fun withPrideHeaderAndFooter(content: @Composable() () -> Unit) {
    VerticalStack {
        ManyCodeForPrideHeader() // Let's assume there's more code there that we don't want to inline.
        content()
        ManyCodeForPrideFooter() // Same as header.
    }
}

The solution would be that the generated code looks like this at call site:

withPrideHeaderAndFooter(before = true) // Runs VerticalStack(before = true) and ManyCodeForPrideHeader()
content() // our lambda is inlined
withPrideHeaderAndFooter(before = false) // Runs VerticalStack(before = false) and ManyCodeForPrideFooter()

instead of looking like this:

VerticalStack { // Possibly much code inlined
    ManyCodeForPrideHeader() // Much code inlined
    content() // We just wanted to inline this lambda
    ManyCodeForPrideFooter() // Much code inlined
}

That may be a little more complex to do if

finally

(and

catch

) blocks are allowed in

@Composable

functions.

Ah I see what you're getting at. Perhaps this could work in some cases. We have some other optimizations we are planning which are not quite the same but similar in concept

I already do this manually (but with two functions, not one with boolean parameter), so inline functions don't inline much apart from the lambda.

@Suraj Shah Note that Compose does not use an annotation processor

@romainguy it doesn't? It has a retention type

BINARY

is that different from

SOURCE

in terms of bloating and processing?

Compose is a special compiler plugin, not an annotation processor

Also note that Compose currently is using minSdk 21, which is ART. Of course that doesn't necessarily mean that it won't change before release, but our current focus is on optimizing for ART's performance characteristics. Of course, ART has also changed a lot since then, so it's a moving target...

Does this mean it's no longer recommended to make functions taking lambdas inline functions when targeting ART? (Slightly off-topic, sorry for that)

Ah, no, that was just in response to Louis's question about Dalvik

the cost/benefit analysis of inline vs not for functions taking lambdas changes in ART, but there are definitely still places where it’s important

So I should have written that this inlining trick might improve performance on all devices then! When I wrote for Dalvik, I thought about how allocation is much more expensive there, but even ART might benefit.