The document provides an update on the performance benchmarking of EFL by Samsung's open source group, detailing efforts to measure memory usage, frame rates, and identify performance regressions. Notable issues include a significant memory leak and unusual increases in process shared memory (PSS), which hindered effective benchmarking within the allocated time. The author discusses the challenges faced and lessons learned in automating benchmarks, along with suggestions for future improvements and integration with existing infrastructure.

1. 1Samsung Open Source Group
Cedric Bail
Senior Open Source Engineer
Samsung Open Source Group
cedric@osg.samsung.com
Update on EFL performance

2. 2Samsung Open Source Group
The plan
● Benchmark memory usage, frame rate and time to first frame
● One week should be enough, right ?
● Use usual tool and experiment with a few new one
– Expedite
– Massif
– Smem
● Walk in a park !

3. 3Samsung Open Source Group
:”(
● Not quite…
● Find memory leak
● Find massive memory usage increase
● Find massive performance regression
● Barely enough time to fix them !

4. 4Samsung Open Source Group
Easiest one, the one I create !
● Massive leak of Cairo context in expedite
● 132MB of leaked data at the end of the test
● Kind of make any other peak impossible to see !
● That one is now fixed

5. 5Samsung Open Source Group
Easiest one, the one I create !
1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16
0
2
4
6
8
10
12
14
Peak

6. 6Samsung Open Source Group
Weird increase in PSS
● Write a script to mesure PSS
● Gathered the data
● Look at it in the plane
● 8-O
● Need to review the script first …
● That's not a fixed problem !

7. 7Samsung Open Source Group
Weird increase in PSS
1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16
0
10000
20000
30000
40000
50000
60000
70000
80000
90000

8. 8Samsung Open Source Group
Run expedite
● Instead of the usual raw benchmark, try to find the reliable test
● Run all expedite test twice on every version since 1.8
● That's 18 runs ! More than 2000 tests…
● Start process them in the plane…
● 8-O
● See major slow down !

9. 9Samsung Open Source Group
Run expedite
1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16
0
200
400
600
800
1000
1200
Image Blend Solid Middle
Border
Image Blend Solid Border
Rect Solid

10. 10Samsung Open Source Group
Run expedite
● Let's blame Tom, because he is not here ! :-) Is he ?
● Then run expedite under callgrind with 1.8 and git
● Issue seems to be related to raster change in region_add
– 1.8: 40% of the benchmark, while drawing was 20%
– 1.16: 80% of the benchmark, while drawing is 5%
● Going to be fun to fix...

11. 11Samsung Open Source Group
So what about the rest ?
● No time for time to first frame benchmarking !
● No time for power consumption benchmarking !
● Memory testing still need fixing

12. 12Samsung Open Source Group
What did I learn
● Automating expedite benchmark is doable if we focus only on a subset
● Expedite does catch regression if we use it…
● How to integrate it with Jenkins and our infrastructure ?
● Maybe put more logic in it to benchmark memory by processing /proc/$PID/maps
● Still no test of elementary/edje at all
● If we don't see the issue when we have tools, then what about when we don't !

13. 13Samsung Open Source Group
Opinions ? Questions ?

14. Thank you.
14Samsung Open Source Group