search

ZupIT / nimbus-compose

Library for enabling Server Driven UI in Jetpack Compose
Apache License 2.0
19 stars 8 forks source link

BaselineProfile considerations, runtime performance considerations #63

Open cayolblake opened 6 months ago

cayolblake commented 6 months ago

@Tiagoperes @hernandazevedozup @arthurbleilzup

I came by your project and understand the goal and problem it's trying to solve, however, is AOT compilation (aka BaselineProfile) is taken into consideration?

I've seen UI composables perform 10-100x faster with BaselineProfiles versus without, so, assuming the UI composables here are generated on the fly, how will it overcome such issue, or wasn't it designed with performance in mind? 🤔

Interested to understand how this project handles such critical issue.

Tiagoperes commented 5 months ago

Hello @cayolblake

The goal of this project was to provide a generic open source solution for implementing Server Driven UI in Android and iOS applications. We also expected to add support for React (web, desktop and mobile).

Unfortunately, it got discontinued. Although there's a chance it will come back, I find it unlikely.

Server Driven UI is, by definition, JIT. JIT will always be slower than AOT, no matter what. This is a tradeoff you must make when using server driven UI, you can't possibly know the UI tree ahead of time, since it will come from the backend and can change at anytime.

It is not the objective of any Server Driven UI tool to replace the whole application with Server Driven Views. It must be used wisely. Which views of the app really need to be driven by the backend? Only them should use SDUI. Moreover, it is likely that an application that uses SDUI for all of its views wouldn't even be accepted in Google Play Store or App Store, the same way apps that are just webviews don't.

or wasn't it designed with performance in mind?

Performance was in our mind for the whole time. We've been very careful with the data structures and algorithms we used. It will just never be as fast as a locally programmed view. There's the overhead of making a request, the overhead of processing the response and the overhead of not being able to compile the UI ahead of time.

Having said this. We've never noticed any lag in any of the examples we created. More often than not, the overhead introduced with tools like these, are not noticeable to the user.

We didn't get the chance to iterate on Nimbus after the first Beta. We'd definitely study better its performance and have metrics to show.