Page MenuHomePhabricator

evas_walk overhead
Closed, ResolvedPublic

Description

I felt latest efl has slowed down after life-cycle patch. here is simple test result.

test case:
ELM_FIRST_FRAME=T EINA_FREEQ_BYPASS=1 ELM_TEST_AUTOBOUNCE=100 elementary_test -to "Scroller 2"
EFL was compiled with gcc 5.4.0 with -O3 -g
CPU : Intel(R) Core(TM) i5 CPU M520 @ 2.40GHz

Before life-cycle patch
commit: 0090384ef5ac9f9e939874a1bbf233298c9db930 (elm_ctxpopup: prevent a giant load of errors)
Startup time: '1528197797.861125' - '1528197797.119980' = '0.741145' sec
NS since frame 2 = 47737910134 , 1407 frames = 33928862 / frame
After life-cycle patch
commit: 311e35a0dd34a9fac6dacce5118a09d07f159d76 (elementary: prevent model from being invalidated when their parent model get destroyed.)
Startup time: '1528198974.667997' - '1528198973.679399' = '0.988598' sec
NS since frame 2 = 44347578100 , 52 frames = 852838040 / frame

I lost 90% frames after life-cycle patch..
I tried to find reason to slow down, finally i found a commit that has problem.

After revert a commit(ddccd9e)
commit: 311e35a0dd34a9fac6dacce5118a09d07f159d76 (elementary: prevent model from being invalidated when their parent model get destroyed.) without ddccd9e
Startup time: '1528199551.564900' - '1528199550.785635' = '0.779265' sec
NS since frame 2 = 47904373707 , 1361 frames = 35197923 / frame

evas_walk/unwalk are called around 180,000times at elementary_test launch time and they are called around 100,000times at one time scrolling with mouse wheel.
Previous evas_walk/unwalk are just increment and decrement operators but now evas_walk/unwalk is efl_ref/unref function calls. (see ddccd9e)
I think it has a huge overhead but to restore evas_walk/unwalk is not best solution.
Does anybody can help to solve this problem?


commit: 311e35a0dd3 with D6244
Startup time: '1528201565.419612' - '1528201564.614091' = '0.805521' sec
NS since frame 2 = 47776926142 , 1062 frames = 44987689 / frame
YOhoho created this task.Jun 4 2018, 7:03 PM
YOhoho edited projects, added efl; removed enlightenment-git.Jun 4 2018, 7:03 PM
YOhoho updated the task description. (Show Details)Jun 4 2018, 7:14 PM
bu5hm4n added a comment.EditedJun 4 2018, 11:36 PM

There is probebly a more bizare bug behind it:
Adding a printf to where unref is called on shows this:

  • We got a few Ecore.Event.Message
  • A few Efl.Input.Pointer (which is weird as they are static)
  • A bizare amount of Evas.Canvas unref calls

Currently invasigating what is up with that

YOhoho updated the task description. (Show Details)Jun 5 2018, 5:32 AM
YOhoho updated the task description. (Show Details)Jun 5 2018, 5:41 AM

Okay, the eo patch at least brings the frame number up again, Is that acceptable ?

I might have a other idea of what we could do there to have some "light" ref counting in evas but the lifetime stuff in eo, therefore i need numbers, can you tell me how often _evas_walk is called when the refcount of the object is > 1 ?

zmike added a comment.Jun 5 2018, 6:49 AM

Is there any way that something like perf can be run (after D6244 is merged) to provide more detailed info on this if it's still an issue at that time?

Okay, the eo patch at least brings the frame number up again, Is that acceptable ?

Yes, that is acceptable :)

I might have a other idea of what we could do there to have some "light" ref counting in evas but the lifetime stuff in eo, therefore i need numbers, can you tell me how often _evas_walk is called when the refcount of the object is > 1 ?

_evas_walk is called 13146 times at elementary_test launch time when the refcount of the object is > 1

In T6983#115327, @zmike wrote:

Is there any way that something like perf can be run (after D6244 is merged) to provide more detailed info on this if it's still an issue at that time?

I've never used perf but i will try

zmike added a comment.Jun 6 2018, 7:24 AM

If _evas_walk is revealed to be the primary consumer of cpu time then it may be a problem that it gets called so many times, but having a function called many times is not inherently problematic. I would wait to see more comprehensive results.

bu5hm4n closed this task as Resolved.Jun 10 2018, 10:45 AM

Okay, lets close this for now.

If we see again that this is a problem, we can still go back to this.

My plan was:

Get back a refcounter to the evas, when we have this ref at == 0 then we call unref, if we are at == 1 after a walk, we call efl_ref.