I am reading @Leland Richardson [G]’s slides and they mention a very specific data structure (flat array) for the UI tree. Some questions: 1) Will the selected data structure have any impact on the semantics of Compose or impose any structural limitations on it (vs a naive tree)? 2) What sources and methods were used to confirm the "the structure of a UI doesn't change very often" assumption (slide 33)? E.i. what frameworks and types of UI did you looked at? 3) Do you know of any use cases that are atypical for the existing UI frameworks, but would fit Compose well that would break the (2) assumption and, as a result, would not have good performance with the Slot Table currently used? I can think of loops with variable number of iterations, but I did not confirm that. 4) If there are valuable use cases in (3) that do not perform well with the current implementation of Compose, how hard will it be to switch Compose to a different (presumably non-flat) data structure?

1) ... structural limitations

No. The data structure is an internal detail. We could switch to a different data structure if performance dictates. We have already switched twice before we went public.

2) What sources and methods ....

Mostly experience with many different frameworks over our careers (for me personally this is my 6th framework). This, however, is just an observation and is not required for the performance of the system. Compose can handle large radical changes in the UI just a easily but we are optimizing around localized changes as that is what we believe will be most common.

3) Do you know of any use cases that are atypical for....

Yes. Inserting and removing nodes at the beginning and end of the slot table in the same composition or any other form of non-local change. As the slot table is a flattening of the of a tree, any non-local changes to the tree will cause copying of the array as the buffer gap moves. If this is common we can introduce multiple gaps or using an internal tree; but, for now, we have a flat array with a single gap.

4) ...how hard will it be to switch...

Not hard. We are keeping the data structure internal and only exposing an abstraction to the code generation to call. We have switched the implementation twice already without impacting the programming model. Even if the code generation takes a more active role (such as producing a scope record to avoid boxing) we still anticipate using the same API as the scope record could just be stored a

memo

like call. We do plan some significant surface changes to the API, moving to a more of a code-flow approach instead of call interception, as explain in Leland's talk which will result in changes to the API the compiler uses but it will still be abstract enough to hide the flat vs. tree based data structure.

Thanks!