1140945 - ProcessDisplayItems spends about 15ms in Homescreen edit mode when moving an item to change the scrollTop

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect, P3)

Description

[Ethan Lin[:ethlin]]

When dragging an item in edit mode, I found that the FPS is 30fps and the most time consuming part is ProcessDisplayItems. There are too many items in the Homescreen, so we need to process about 70 items in the ProcessDisplayItems.

Comment 1

[Ethan Lin[:ethlin]]

Attachment: Profile result

Comment 2

[Ethan Lin[:ethlin]]

Attachment: Profile result

After bug 913443, the profiler is as attached file. The result is similar. The difference is just the large part becomes PopPaintedLayerData from ProcessDisplayItems.
Is there any possible way to improve the PopPaintedLayerData performance when there are a lot of items? Do you think multi-thread for AddPaintedDisplayItem is a good idea?

Comment 3

[Markus Stange [:mstange]]

(In reply to Ethan Lin[:Ethan] from comment #2)
> Is there any possible way to improve the PopPaintedLayerData performance
> when there are a lot of items?

One fairly simple optimization I can see is to avoid doing duplicate work in the loop that iterates over mAssignedDisplayItems. We could pull the loop into InvalidateForLayerChange and into AddPaintedDisplayItem (making two separate loops out of it). Then we could at least call this only once:

  PaintedDisplayItemLayerUserData* paintedData =
    static_cast<PaintedDisplayItemLayerUserData*>
      (layer->GetUserData(&gPaintedDisplayItemLayerUserData));

instead of for each item. And maybe other caching opportunities would become apparent.

> Do you think multi-thread for
> AddPaintedDisplayItem is a good idea?

I expect it won't be easy to separate the shared state mutating parts from the non-mutating parts of the code. Let's not think about this until we've exhausted the single threaded optimization opportunities.

Comment 4

[Markus Stange [:mstange]]

By the way, it looks like bug 913443 caused a real performance regression, see bug 1141247. Once I have profiles of the regression, I might have more ideas for optimization opportunities.

Comment 5

[Markus Stange [:mstange]]

Attachment: part 1: pull two hashtable lookups out of a loop

Comment 6

[Markus Stange [:mstange]]

Attachment: part 2: avoid an array copy by making ClippedDisplayItem and AssignedDisplayItem the same

Comment 7

[Markus Stange [:mstange]]

Attachment: part 3: clean up arguments of FrameLayerBuilder::AddPaintedDisplayItem

Comment 8

[Markus Stange [:mstange]]

Attachment: part 4: rename cdi to assignedItem

Comment 9

[Markus Stange [:mstange]]

Ethan, can you test whether these patches make a noticeable difference? They didn't help on bug 1141247.

Comment 10

[Ethan Lin[:ethlin]]

Markus, thanks for your patches. I tried your patches and the performance has no difference in my case. For now I am also studying the performance issue around here. I will let you know If I have any discovery.

Comment 11

[Markus Stange [:mstange]]

Thanks for testing.

Comment 12

[BMO Automation]

Firefox OS is not being worked on