Page MenuHomePhabricator

[MVVM] Efl.Ui.View_List Performance Improvement
Closed, ResolvedPublic


In current Efl.Ui.View_list,
if we add 1000 children in the model,
widget itself cannot be launched in the efl_ui_viewlist_example_01.c

we need to improve and optimize performance in model and efl.Ui.View_List,
especially size_calculation of each items need to be improved for normal usages.

using item instead of layout can be one good solution.
efl.ui.layout_object will evaluate their own size by given edje,
so we cannot optimize item calcalation proper times.

model slice range and layouter optimization also we need to check.

SanghyeonLee updated the task description. (Show Details)Sep 10 2018, 1:46 AM

I'm not sure it is possible to optimize that much, maybe we should run a profiler and see where the CPU usage is. But, we can't slice it less because calculation needs to be done for all items for perfect scroll size.

so the better solution for optimizing is applying homogeous size of items for most useless size calculations.
but though we need to calculate every items in the list,
we could give some trick for them to optimize calculations.

calculate small chunks in each loop can be good solution though it takes long time to show whole scroll sizes.
we do not need to guarentee whole scroll size in the first launched view in my thought.

cedric added a subscriber: cedric.Nov 16 2018, 11:06 AM

Yes, for non homogeneous case, we should have a callback that only update small portion at a time and doesn't over consume the main loop time. We can push an estimate of the scroll size by using an average of the currently calculated item. That is I think our best strategy there.

yeah agreed. and we could apply new feature of extendable scroller... like, we read only small range of model and create scroller with this items,
when it reached end of the scroller, we request another bunch of items, like, extending scroller as it's edge.
android and ios and some web site like facebook or twitter already using this kind of scroller concept widely, so we could support this in MVVM level. what do you think about this?

Let's keep the discussion about range API inside T7378 for the moment.

I have been giving some more additional thinking about homogeneous case and additional possible computation mode. If we had a set of internal model that would provide the following :

  • Homogeneous model, until one object write its size as a property in it, the size property return EAGAIN. After the first write, it return the size defined. The parent model store that size and expose it also as a property.
  • Average size model, return EAGAIN until an object write a size property in it. The parent provide an average of all the currently calculated item size, the amount of object that have been calculated and an estimate of the size of the total model.
  • Exact size model, return EAGAIN until an object write a size property in it. The parent expose only the total currently calculated as its total size.

This way, we could connect the scroller size directly to a property on the parent model and the size of an item to the connected model on the item. The logic in efl_ui_layout.c:_sizing_eval could implement the case when the object is connected and there is a size property connected to have the above behavior (If the model return EAGAIN, do the calc and call property_set, if the model return a value use it, if the property value change reflect that change).

From any of the view perspective, when a model is set or when the homogeneous property is changed, it will destroy all currently build items and redefine the chain of composited model to include the right sizing model. From there it will restart the process of computing the size of everything. There would still be needs in the view to understand this different mode so that it doesn't walk all the object in the case of the homogeneous and average.

Additionally this open to work on optimizing the storage of size information inside the model. We could for example have a sparse array with some tree structure and leaf are usually compressed except when the child model exist in which case it is uncompressed. This would improve memory usage for large data set. The size should have some nice property for compression. Anyway that are idea for later.

SanghyeonLee added a comment.EditedDec 26 2018, 4:01 AM

I've got lots of requirements regarding size calculation and your idea about average size model looks very helpful for them.
so you meant VIewModel also have some helper and properties for size on it,
and they can change the SizeModel as their circumstance what it need to be work?
If I'm right, I think its good idea.
@felipealmeida what do you think about this?
if you agreed also then let's start with homogeneous first, and after that will go exact and average.

Additionally, this is secondary work I guess,
I've recently got some request about genlist improvement by using buffer scroll.
It means, do not move the item manually by scroll moves,
draw the item in image buffer, and when it scrolls,
move the buffer only so reduce scene graph traverse and move function calls.
I think it may be possible by using map in our case.
I've heard some framework (android or IOS) do the optimization by this way,
but I'm not sure this will be helpful to improve scrolling performance.

how do you think about this? @cedric @felipealmeida

@SanghyeonLee I have added T7381 to track the scroll optimization using buffers.

I will start working on Homogeneous model next week.

zmike moved this task from Backlog to Felipe on the efl: mvvm board.Jan 9 2019, 12:26 PM

This doesn't apply any more. I will start another set of task regarding optimization of MVVM infrastructure and List/Grid component too.

cedric closed this task as Resolved.Oct 10 2019, 4:20 PM