[Keyboard] About 5% higher CPU load on Flame device when keyboard is shown

NEW
Unassigned

Status

Firefox OS
Performance
P2
major
3 years ago
a year ago

People

(Reporter: whimboo, Unassigned)

Tracking

({perf, power})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c=cpu p= s= u=][perf-wanted][Power:P3])

(Reporter)

Description

3 years ago
Gaia      597975839c04e0198eb98c2c77474f057b5531e7
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ddeead927143
BuildID   20140805000238
Version   32.0
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

While I was stumbling over bug 1021400 today, I was doing some more checks with 'top -m 5' enabled. What I have seen is that whenever the keyboard is open, the cpu load increases by about 5% on my Flame device! That's a lot of processing power for a software, which is in idle mode. Why does it take so much? 

Steps:
1. Enable developer options
2. Run 'adb shell top -m 5'
3. Open a screen with a text field but don't tap on it yet
4. Lets wait until the cpu load has been settled
5. Open the keyboard
6. Lets wait until the cpu load has been settled

In case of step 4 I see a load of about 8% of the b2g process for most of the apps. But for step 6 it is already 13%, which doesn't go down even waiting a longer time.

So keeping the keyboard open even in idle mode will drain your battery faster.
CPU profile?
(Reporter)

Comment 2

3 years ago
If you tell me how to do that, I could have a look at tomorrow.
(Reporter)

Updated

3 years ago
Flags: needinfo?(khuey)
Does not happen to me on Flame running 2.0 with 2.1 Keyboard.
Also when looking at |adb shell b2g-info| the Keyboard process doesn't consume any CPU when open.
(Reporter)

Comment 5

3 years ago
It's not the keyboard process which takes higher CPU load but the b2g process itself.

Updated

3 years ago
Priority: -- → P2
Whiteboard: [c=cpu p= s= u=]
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_Boot_to_Gecko_%28with_a_real_device%29
Flags: needinfo?(khuey)
Hi Henrik,

Could you please help provide the result of your "top" command, from "UID" column, we could know if it is keyboard process that consume the CPU usage.

This is mine when trying to repro with a keyboard launched with message app (UID: u0_a1544),
===
  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
19263  0   2% R     1   1316K    560K     root     top
 1709  0   2% S    66 261140K 102740K     root     /system/b2g/b2g
   98  0   1% S     1      0K      0K     root     ksmd
15447  0   1% S    17  90600K  29044K     u0_a1544 /system/b2g/b2g
   23  0   0% S     1      0K      0K     root     kworker/u:1H


Did not see keyboard process in this list.

--
Thanks for filing this issue.
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #5)
> It's not the keyboard process which takes higher CPU load but the b2g
> process itself.

Move to General per comment above.
Component: Gaia::Keyboard → General
Wait, why is there a keyboard process at all?  I thought the built-in keyboard is in-process?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #9)
> Wait, why is there a keyboard process at all?  I thought the built-in
> keyboard is in-process?

No, we run it only in process on low-spec devices.

Updated

3 years ago
Component: General → Performance

Updated

2 years ago
Whiteboard: [c=cpu p= s= u=] → [c=cpu p= s= u=][perf-wanted]
We need to have profiling data to prove this issue.
Assignee: nobody → kchen
tracking-b2g: --- → +
Whiteboard: [c=cpu p= s= u=][perf-wanted] → [c=cpu p= s= u=][perf-wanted][Power]
There's not much data here which makes it hard to move forward.
Whiteboard: [c=cpu p= s= u=][perf-wanted][Power] → [c=cpu p= s= u=][perf-wanted][Power:P3]
(Reporter)

Comment 13

2 years ago
I don't have an up2date device anymore to be of help.
Flags: needinfo?(hskupin)

Updated

2 years ago
Assignee: kchen → nobody
tracking-b2g: + → ---
You need to log in before you can comment on or make changes to this bug.