Closed Bug 820310 Opened 12 years ago Closed 12 years ago

[B2G SMS] Multiple markMessageRead() calls causes significant performance issues

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
B2G C3 (12dec-1jan)
blocking-basecamp +

People

(Reporter: ferjm, Assigned: ferjm)

References

Details

(Whiteboard: [drop if not fixed by 1/2 (2wks)])

Attachments

(3 files, 1 obsolete file)

As explained in https://bugzilla.mozilla.org/show_bug.cgi?id=813978#c48 multiple calls to |markMessageRead()| causes a pretty bad performance issue when entering in an SMS thread message view. This bug is supposed to track the required work, in the platform or in the UI side, to improve this performance.
Blocking a blocker, so bb?
blocking-basecamp: --- → ?
Depends on: 771463
Assignee: nobody → ferjmoreno
I suggested we try the following approach in the UI:

function markMessagesRead(ids) {
  var id = ids.pop();
  navigator.mozSMS.markMessageRead(id, true).onsuccess = function() {
    if (ids.length) {
      markMessagesRead(ids);
    }
  };
}

If that shows to be too slow, we can look at changing the API.
Attached patch Gaia test (obsolete) — Splinter Review
As you can see in the attached logcat, the gaia modifications to chain the calls to |markMessageRead()| are not helping that much :(. For some reason, the first call to |markMessageRead()| when entering in a message view sometimes takes like forever...
I'll try to debug the platform side to see where are we spending that much time.
blocking-basecamp: ? → +
Priority: -- → P3
Depends on: 815260
No longer depends on: 771463
Priority: P3 → --
No longer depends on: 815260
Depends on: 815260
I've been doing some more tests and it seems that the problem wasn't in the platform but on the Gaia side. We were calling |getMessages| without a filter (which means that we were following the painful slow path for getting all the messages) after marking the messages as read. After removing this call to |getMessages| the logs show that the times retrieving and marking the messages as read are pretty decent. I am attaching a small sample of this logs.

I've been talking with Borja and he recommended me to wait until Bug 815260 lands before sending any PR with the required modifications to chain the calls to |markMessageRead|.
No longer depends on: 815260
Target Milestone: --- → B2G C3 (12dec-1jan)
blocking-basecamp: + → ---
Whiteboard: [drop if not fixed by 1/2 (2wks)]
blocking-basecamp: --- → +
Priority: -- → P2
I'll have a patch for this issue this week.
Attachment #690903 - Attachment is obsolete: true
Comment on attachment 694903 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7149

I'd like to add the functionality to mark the thread as read (visually) as soon as it is clicked as that would be a better UX. How can I do that Borja?
Attachment #694903 - Flags: feedback?(fbsc)
Only one issue. Check in Github the following:
https://github.com/mozilla-b2g/gaia/pull/7149#issuecomment-11651095

The rest of the code looks great! Thanks for your support ;). Let me know when you fix it and I will review it again.
Thanks Borja, I've just addressed your feedback and also added the ability to visually mark the thread as read just right after clicking on it to change to the message view (as I requested in comment 8). This way, even if all the messages are not still marked as read in the db, if the user gets back to the thread view, she will see the thread marked as read, which means a better UX.
Attachment #694903 - Flags: feedback?(fbsc) → review?(fbsc)
Attachment #694903 - Flags: review?(fbsc) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: