[Benchmark] Are there some full benchmarks for Redwood?

[xiaobailong24]

I have found some benchmarks for zipline: https://github.com/search?q=repo%3Acashapp%2Fzipline+benchmark&type=pullrequests.

And what about Redwood?

Thx.

[JakeWharton]

What part would you want to see benchmarked exactly?

[xiaobailong24]

Thanks for your reply. I am very interested in Kotlin Multiplatform (depending on Kotlin/JS) logic and UI support dynamics, and optimistic about future development scenarios. Thanks to cashapp, which has always been at the forefront of technology, for exploring and opening up in this area. For the current popular cross-platform frameworks (although the README notes that Redwood is a library, not a framework, but it should solve similar problems), one of the concerns is performance, whether it is Flutter or React Native, compared with native there will be gaps. While Reactive UIs and dynamization may be the core goals of Redwood, it may be more meaningful and promising if it can be combined with high performance.

So, regarding the performance of Redwood:

1. On the one hand, from the perspective of core principles, Redwood is based on Zipline (Kotlin Multiplatform + QuickJS) . According to the https://github.com/cashapp/zipline#fast, Zipline has been partially optimized for performance bottlenecks:

   • JS engine: QuickJS is small and fast;
   • AOT: Zipline precompiles JavaScript into efficient QuickJS bytecode to improve runtime code execution efficiency; (Of course, I also look forward to the evolution of Zipline 2.x version after Kotlin/Wasm is stable)
   • Modular & Download-Concurrently & Cache: Eliminate the performance loss of code downloads.

   But there will still be the following bottlenecks affecting performance:

   • JS code can only be executed in a single thread (no essential difference from React Native)
   • Interface bridging uses serialization (similar to React Native old architecture)
     • By default, arguments and return values are pass-by-value. Zipline uses kotlinx.serialization to encode and decode values passed across the boundary.

2. On the other hand, from the perspective of the upper UI layer, Redwood is based on Compose.

   • At present, the performance of Lazy List of Jetpack Compose based on similar self-rendering principle and the performance of native RecyclerView will be somewhat different, so Redwood based on JS engine should be worse.

In summary, theoretically, there will definitely be a performance gap between Redwood and the Native. However, what is the specific gap, I expect to have a full benchmarks test:

• QuickJS: Performance comparison with other JS engines, and native (Kotlin/Java, Objective-C/Swift) performance comparison, such as Fibonacci; (maybe others have already tested it, so you can quote it)
• Zipline: Kotlin/JS package size impact, etc.;
• UI: above the first-screen-time, interaction (Click/Scroll), especially long lists.

These are my personal thoughts, looking forward to your reply.

[xiaobailong24]

@JakeWharton Hi jake, any plans for benchmarks?👀

[JakeWharton]

Maybe eventually, but it's not a priority or focus right now. Some things are fairly optimized already (the protocol), and some things are not. We don't have the time to spend on this right now because there's still so much to build in order to productionize the tool.

[xiaobailong24]

Got it. Thanks again.