846905 - Browser launch latency is high during load

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Gaia::Browser, defect, P2)

Description

[[e-mail]]

In normal cases launch seems to be ok. But in loaded scenario (while other apps are in back ground) browser launch seems to be taking more time.

Comment 1

[[e-mail]]

In normal scenario it is observed that browser launches in 1.5 secs. But in a low memory scenario (tested with 256MB) it is observed that browser is taking upto 2.5 secs to launch.

Comment 2

[Michael Vines [:m1] [:evilmachines]]

(there's a strong desire to fix this for tef, but I think we need more analysis still so assigning to Godavari for now)

Comment 3

[Justin Lebar (not reading bugmail)]

Can you please give concrete steps to reproduce?  Exactly which apps are you loading in the bg?

Comment 4

[Justin Lebar (not reading bugmail)]

Can you also please attach the logcat from when this occurs?

What I suspect may be happening, from the way you describe it here, is that we're running memory-pressure events while the browser is loading, and that's what's making loading slow.

Comment 5

[[e-mail]]

Yes Justin, you are right. This may not be a scheduling issue. It is happening only on 256MB devices but not 512MB. 

Browser get kills due to the lowmemory when first visit a particular page and  then launch some other applications including background music and then visit back to the browser which is expected to reload the same page quickly. 

But it is really taking long time as it is not only launching but reloading again, and trying killing some other apps if memory is required or so. 

Here is the loop we follow for finding the first and subsequent latencies. The second time browser launch (subsequent is taking more time from 2.5 to 4 secs).

Boot Up the Phone
Launch Contacts (atleast 200 contacts) 
Scroll through the contacts
Go to Home Screen
Launch music app - Launch Latency
Start playing first audio clip
Go to Home Screen 
Home screen pan 
Applist scroll 
Go to Home Screen
Launch Browser and load cached pg (Google home page) 
Go to Bookmarks and load static browser scroll page like NYtimes.
Browser vertical scroll
Go to Bookmarks and load static browser zoom page
Browser Zoom 
Go to Bookmarks and load cached pg (Google home Page)
Go to Home Screen
Launch Email 
Email vertical scroll
Go to Home Screen
Launch SMS
Scroll through the SMS
Go to Home Screen
End of sequence

Will upload the logcat also for your analysis.

Comment 6

[Justin Lebar (not reading bugmail)]

> Browser get kills due to the lowmemory when first visit a particular page and  then launch some 
> other applications including background music and then visit back to the browser which is expected 
> to reload the same page quickly. 

In the sequence you posted, I see only one instance of "Launch Browser".  But it sounds like you're saying here that we launch the browser twice, right?

> Browser get kills due to the lowmemory when first visit a particular page and  then launch some 
> other applications including background music and then visit back to the browser which is expected 
> to reload the same page quickly. 

> But it is really taking long time as it is not only launching but reloading again, and trying 
> killing some other apps if memory is required or so. 

Okay.  The only thing here as far as I understand that sounds like it might be a bug is that perhaps the low-memory notifications are causing a slowdown.

Are you able to do custom builds?  If so, could you please open up widget/gonk/GonkMemoryPressure.cpp and comment out the contents of InitGonkMemoryPressureMonitoring() at the bottom of the file and test with that change?

If you're unable to do custom builds, you /may/ be able to get a similar effect by writing 0 to /sys/module/lowmemorykiller/parameters/notify_trigger:

 $ adb shell echo 0 > /sys/module/lowmemorykiller/parameters/notify_trigger

This should disable the low-memory notifications.  You should just periodically check that b2g doesn't overwrite your change:

 $ adb shell cat /sys/module/lowmemorykiller/parameters/notify_trigger
 0

With low-memory notifications disabled (however you do it), do things work better?  Also please attach a logcat in any case of your new tests.

Comment 7

[[e-mail]]

Attachment: Logcat

Logcat file browser substitute launch

Comment 8

[[e-mail]]

Yes it is basically a browser launch twice to see the subsequent launch time. Due to the memory load from the other applications browser takes much time to launch (if it was killed) and reloading the previously visited page hence taking time. 

Will do the modification and check.

Comment 9

[Justin Lebar (not reading bugmail)]

Comment on attachment 721427 [details]
Logcat

I don't see any low-memory notifications in here, so I guess, contrary to my expectations, that's probably not relevant.  Perhaps this is an issue of CPU scheduling.

Comment 10

[[e-mail]]

Is there any way we can set the home page in the browser so that it loads the same page when we launch? Currently I see thumbnails in the home page. But the subsequent launch reloads the previously visited page if it is killed. There will  also be some differences coz of this.

Comment 11

[Justin Lebar (not reading bugmail)]

> Yes it is basically a browser launch twice to see the subsequent launch time.

In the steps to reproduce from comment 5, I only see the browser being launched once.  Do those steps not cover your full procedure?  Or, are those steps a loop?  You go back to "Launch Contacts" after "End of sequence"?  Sorry, it's not clear.

Comment 12

[Justin Lebar (not reading bugmail)]

(In reply to [e-mail] from comment #10)
> Is there any way we can set the home page in the browser so that it loads
> the same page when we launch? Currently I see thumbnails in the home page.
> But the subsequent launch reloads the previously visited page if it is
> killed. There will  also be some differences coz of this.

You can modify the code so it does this, but in the end, I don't think it's useful to do tests that don't match the performance characteristics of the device we're shipping.

Comment 13

[[e-mail]]

Sorry for the confusion, yes they are in loop and we have to repeat for subsequent launch times.

Comment 14

[[e-mail]]

Overall there is gap in comparison between first launch (blank page) and second launch (previously loaded page) in loaded scenario that causes more time.
We should try to reduce the gap. 
Are we trying to reload the entire page in second launch or do we cache the contents?

Comment 15

[Ben Francis [:benfrancis]]

(In reply to [e-mail] from comment #10)
> Is there any way we can set the home page in the browser so that it loads
> the same page when we launch? Currently I see thumbnails in the home page.
> But the subsequent launch reloads the previously visited page if it is
> killed. There will  also be some differences coz of this.

The browser app always shows the start page when it is launched. If you switch to another app and then switch back to the browser app you will continue using the app where you left off, as is the case for all apps. In low memory conditions, individual browser tabs can get killed. If you switch back to the browser app and the selected tab has been killed, the page will be automatically reloaded. How long that page takes to reload is largely dependent on the speed of your Internet connection.

This is all to specification and expected. I'm not sure what the bug is here?

Comment 16

[[e-mail]]

Yes Francis. We too realized that the behavior is different between first launch and subsequent launch-after killed due to low memory which was not the case in Android, where it could directly takes us to the home pages. 

Firstly, reduced the priority to  P2. Will also ask someone to remove tef+\blocker flag as its not actually a critical issue. 

Second, it will still be bad for the user to wait for long time (some times upto 5 secs) to bring the app\page forward that was killed which he wasn't aware of. So, we need to see if we are making use of our best optimizations like using cached resources\pages. Can someone comment on the same and provide inputs on we best we can do.

Comment 17

[Andrew Overholt [:overholt]]

(In reply to [e-mail] from comment #16)
> Firstly, reduced the priority to  P2. Will also ask someone to remove
> tef+\blocker flag as its not actually a critical issue. 

Done :)

Comment 18

[Michael Vines [:m1] [:evilmachines]]

Closing this bug because seems it has run it's course.