Closed Bug 929996 Opened 11 years ago Closed 10 years ago

[e.me] Loading first E.me file takes too long

Categories

(Firefox OS Graveyard :: Gaia::Everything.me, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:-)

RESOLVED FIXED
2.1 S1 (1aug)
blocking-b2g -

People

(Reporter: amirn, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=progress p=2 s=2014.08.01.t u=])

setup:
connect a FXOS device to computer and run 'adb logcat | grep EVME'

STR:
1. restart 'homescreen' so E.me files are not loaded
2. click a collection
3. observe that several seconds pass until the first E.me file is loaded (first log message by E.me)
4. after the first file loads, the rest of the files load faster

Expected:
The first file is loaded immediately after the click event
Evyatar, can you please provide more information?
Flags: needinfo?(evyatar)
Blocks: 914875
Whiteboard: perf
No more info about this. it's something we witnessed while working on 1.2 - the first files being loaded take up to a few hundred ms, and then the following files are almost instant (usually an avg of 20ms).

I did some debugging on this, and it's really just the loading of the file that takes long. even if you load empty JS files - the first ones will take a lot of time.
Flags: needinfo?(evyatar)
No longer blocks: 914875
Blocks: 914875
Who is the right person to assign this?
Flags: needinfo?(mlee)
Amir,
We're tracking this issue in our backlog but are currently focused on 1.2 blockers this sprint (11.08). I'm noming this for 1.3 so we can triage and find an assignee after 11.08.
blocking-b2g: --- → 1.3?
Flags: needinfo?(mlee)
Keywords: perf
Whiteboard: perf → [c=progress p= s= u=]
QA Contact: dhuseby
Whiteboard: [c=progress p= s= u=] → [c=progress p=2 s= u=1.3]
Assignee: nobody → dhuseby
QA Contact: dhuseby
Priority: -- → P2
Status: NEW → ASSIGNED
blocking-b2g: 1.3? → -
Whiteboard: [c=progress p=2 s= u=1.3] → [c=progress p=2 s= u=]
We minus for v1.3 because the scope of the problem is limited to the first load and the impact is just a few hundred milliseconds.  We should fix it, but it's not of a magnitude that justifies blocking v1.3.
Dave, I'd like you to reconsider as I believe fixing this issue would gain seconds (not mili) of loading time.

Notice that it's quite ok when clicking on the search bar for the first time (on every boot) but it's much more apparent when opening a Collection or adding a new one. It can lead up to accumulated 7+ seconds of progress indicator as the e.me server requires init and communication.
Flags: needinfo?(dhuseby)
Yes you are right there is a problem.  The 1.3 minus just means we won't hold up the 1.3 release.  This bug should get fixed but before we do that, can you profile it and get some solid data.  Here's the documentation for the profiler we use: https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

If you need help interpreting the results, attach them here and needinfo me again and I'll see what I can do to help you.
Flags: needinfo?(dhuseby) → needinfo?(ran)
Hey Dave, I can't user profiler.sh as we don't build our own b2g and using the Nightly profiler doesn't seem to yield any informative results.

I think it's better I let the perf pros handle this.
Flags: needinfo?(ran)
I won't be able to get to this until February.  Is there are reason you are not building your own b2g?
Flags: needinfo?(ran)
Assignee: dhuseby → nobody
We've never needed to and the times we tried installing it and all it's dependencies were very difficult and time consuming.
Flags: needinfo?(ran)
No longer relevant in Vertical homescreen.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [c=progress p=2 s= u=] → [c=progress p=2 s=2014.08.01.t u=]
Target Milestone: --- → 2.1 S1 (1aug)
You need to log in before you can comment on or make changes to this bug.