Closed Bug 923949 Opened 11 years ago Closed 10 years ago

[Template] Template application is slow

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
1.3 C3/1.4 S3(31jan)

People

(Reporter: kgrandon, Assigned: kgrandon)

References

Details

(Keywords: perf, Whiteboard: [c=progress p= s=2014.01.31 u=]) 

The current template app startup time is ~300ms. I think the goal should be < 100ms. Improving this will improve all apps.
Some notes: 

It takes between 20ms and 40ms from homescreen tap event handler until the system app gets the webapps-launch mozChromeEvent.

From the time that the system app gets the message and actually launches the app, it takes ~100 ms. I think the first step is to see if we can lower the amount of time that the system app is taking here.

Also had a chat with Vivien and it appears that we are doing some work to move CSP into C++. This will mainly help apps which load tons of resources, but it may help the template app a bit also.
Depends on: 924032
There is about 140ms of painting at time 2660.  That seems somewhat excessive given there is almost zero DOM and CSS.  It appears to be context switching between the parent and child process during this period.  Is this expected?  What IPC is necessary during painting?
Hey Matt, Benoit - I was told that you guys might be a good resource to look into this profile. If you have the time, I would greatly appreciate if you could take a quick look. Thanks!
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bgirard)
Any chance we can throw in a marker in the b2g process from the point where it decides to start the other process? It's not clear at which point the main process decides to start the other app before which we're not interested in the data.
Flags: needinfo?(bgirard)
The time spent during |IPDL::PBrowser::RecvShow| is a bit concerning. It looks like it delayed by the main process handling other queued events before it can get to them. Particularly we have two long refresh ticks. Perhaps its the app open animation but we need to dig down and figure out what is being painted during that time. There's also |IPDL::PContent::RecvAsyncMessage| which I'm not familiar with which is concerning.
Kevin, if this is really a blocker to bug 920713 please koi? it as well as its blocker bug 924032.
Flags: needinfo?(kgrandon)
Whiteboard: [c= p=4 s= u=] → [c=progress p=4 s= u=]
Noming as this blocks a blocker.
blocking-b2g: --- → koi?
Flags: needinfo?(kgrandon)
Going to hold off on koi nomination for now until we can ensure that this is actually a regression. Bug 920713 uses a different Hello World application, so we could see if we can standardize on a single app. Unblocking for now.
No longer blocks: 920713
blocking-b2g: koi? → ---
Depends on: 834622
Flags: needinfo?(matt.woodrow)
Nothing immediately actionable besides investigation, and there has been a bunch of improvements here recently. Closing this.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [c=progress p=4 s= u=] → [c=progress p= s=2014.01.31 u=]
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
You need to log in before you can comment on or make changes to this bug.