Closed Bug 833674 Opened 11 years ago Closed 11 years ago

Prelaunched processes startup only marginally faster than non-prelaunched ones

Categories

(Core :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 819000

People

(Reporter: gsvelto, Unassigned)

References

Details

While measuring the impact of the patch in bug 786631 we discovered that prelaunching the camera application gained only 200ms instead of the 600ms we expected compared to the non-prelaunched version. This was due to the prelaunched application having a total launch time (prelaunch time + actual launch) which was ~400ms longer then the launch time of the non-preloaded app.

Profiling the template application showed a similar behavior, this is the non-prelaunched app starting up, totale startup time is ~1.2s:

http://people.mozilla.com/~bgirard/cleopatra/#report=a85b122c1f323253cb9ee322f28303111e6625b0

This is the prelaunched app, the prelaunch phase lasts ~0.6s and the actual launch 1s so ~1.6s in total:

http://people.mozilla.com/~bgirard/cleopatra/#report=15dc4e0c9ff20b64dc607c3329e34c48dd834bea

The tests were done on an Otoro phone using the mozilla-b2g18 branch for the Gecko build.
I have repeated the test with the patch from bug 819000 applied and it seems that besides speeding up the launch process significantly it also seem to fix this particular quirk.

This is the template app starting with preloading, the visible launch time is only ~480ms and the total aggregated startup time ~1300ms, barely more than what it takes to launch w/o prelaunching:

http://people.mozilla.com/~bgirard/cleopatra/#report=8879cdc8e626d755cd805175042a11f7d255c06c
Depends on: 819000
I'm not 100% sure what's being tested here, but note that the prelaunch process runs with "background" priority during its prelaunch phase (on purpose!), so adding up prelaunch-time + app-launch-time and comparing it to non-prelaunch-app-launch-time is not valid.  When there's no prelaunch, the app loads entirely with "foreground" priority.

But if I'm misunderstanding, ignore me ;).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> I'm not 100% sure what's being tested here, but note that the prelaunch
> process runs with "background" priority during its prelaunch phase (on
> purpose!), so adding up prelaunch-time + app-launch-time and comparing it to
> non-prelaunch-app-launch-time is not valid.  When there's no prelaunch, the
> app loads entirely with "foreground" priority.
> 
> But if I'm misunderstanding, ignore me ;).

No, you're concern is quite valid. I've increased "dom.ipc.processPrelaunch.delayMs" to 5000ms for my testing so that the prelaunched app starts up while the phone is idle precisely so that it won't be affected by a foreground. The issue here is that if you compare the actual start time is only ~200ms faster with prelaunch than w/o while we expected ~600ms. At least I assumed that because it was the length of the pre-launch phase.

I'll test more apps with your patch applied to see if I can reproduce this behavior. If I can then you'll probably want to change the whiteboard note on bug 81900 from [fast:300ms] to [fast:500ms].
Oh, my estimate of the win for prelaunching Camera was based on stopwatch timing before/after the patch (up to first "real paint").  Which number are you looking at here?
fwiw: as I mentioned in bug 834079 comment 9 - I cannot reproduce startup perf difference with dom.ipc.processPrelaunch.enabled on and off at all.
I can confirm that this removes the preallocated process (./profile.sh ps doesn't show it) but the startup speed remains the same.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> Oh, my estimate of the win for prelaunching Camera was based on stopwatch
> timing before/after the patch (up to first "real paint").  Which number are
> you looking at here?

I was looking at the activity in the profiler up to the first long wait pause (which happens right before the screen starts refreshing). See bug 786631 comment 23.
(In reply to Zbigniew Braniecki [:gandalf] from comment #5)
> I can confirm that this removes the preallocated process (./profile.sh ps
> doesn't show it) but the startup speed remains the same.

That doesn't surprise me, that's the same behavior we had observed here by running two phones side-by-side and it's the reason why I opened this bug. Try again with the patch in bug 819000 applied, the difference before prelaunch/no-prelaunch becomes very apparent then even to the naked eye.
This is the camera app w/o pre-launching, time before we start refreshing the screen looks ~3.5s:

http://people.mozilla.com/~bgirard/cleopatra/#report=40d5408a8d23b67bb82148ed4178742b34b00dcf

This is with the patch applied:

http://people.mozilla.com/~bgirard/cleopatra/#report=6b2a1390aa665976a5b8d9613909d6f550ea8ace

Launch time is down to ~3s which is consistent with the other tests I made. Without the patch in bug 819000 the speedup for pre-launching was only ~200ms.

If you measure the total time (pre-launch + launch) it's still above total time w/o pre-launching but this is normal in this particular case because we run a bunch of memory minimizations on the pre-launched app which are bound to slow it down a bit when it starts again.

Since the issue in this bug seemingly went away with bug 819000 I'll close the bug as duplicate if everybody is OK with that.
Since the patches in bug 819000 have landed the template app launches in ~0.5s when pre-launched vs ~2.0s when started directly so I'll close this bug as a duplicate.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.