817154 - Launching the maps app results in the phone being unresponsive for seconds at a time over a period of minutes

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect, P4)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Instead of going through douchebag appcache.

The current first-run experience of maps is atrocious.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Hey Donovan, how's this coming along?  The experience of installing the maps app on NAND flash is far and away the worst UX issue in our default build.  The phone is unusable for minutes, even over wifi.

Comment 2

[Donovan Preston [:fzzzy]]

I was just discussing this with Nokia; they have sent me a package containing the code which I am going to be testing as a preinstalled package.

However in case there are any difficulties getting this working, will the appcache warming code in external-apps/cache_sync.py be able to help at least the initial startup?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

For all our sakes, I hope so :/.

Comment 4

[Donovan Preston [:fzzzy]]

heh

Comment 5

[David Scravaglieri [:scravag]]

Let us know when a decision related to feasability and stability has taken and renominate if needed

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

There's no concern about feasibility or stability.

Please see comment 1, and ideally try to use the maps app on a newly flashed otoro.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-, P4 - first run (only) performance issue 
tracking-b2g18+

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Fabrice, do the pre-packaged external-apps get installed into /data on firstrun?  Or must they continue to be updated through /system updates?

Comment 9

[[:fabrice] Fabrice Desré]

Preloaded 3rd party apps are installed on /data, and can be updated "normally", without a full gecko+gaia update.

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Beautiful.  To be clear, this applies to packaged apps too right?

Comment 11

[[:fabrice] Fabrice Desré]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
> Beautiful.  To be clear, this applies to packaged apps too right?

That applies only to packaged apps currently. For some reason I don't remember, we don't move the hosted preloaded apps to /data. We still update their appcache though.

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Donovan, any progress?  I would approve this so hard ... ;)

Comment 13

[Donovan Preston [:fzzzy]]

Hah, I wish, I really haven't had time to get to this, sorry. I'll see if I can find some time.

Comment 14

[Josh Carpenter [:jcarpenter]]

Attachment: Video of Maps performance on first run, Jan 8

The attached video shows the severity of the problem. Check out the load time of of the Settings app at 1:08, for example. And this video is actually better than I've seen in other circumstances, wherein the Home screen panning also completely broke. 

This is a top priority for UX. Performance problems of this magnitude severely degrade the quality of the experience, and will frustate our users beyond what is acceptable.

Comment 15

[Gabriele Svelto [:gsvelto] (PTO)]

We've noticed this today with Vivien while doing some testing, during the slow-down time the rest of the phone was almost unusable and even once the I/O had finished the maps application would not respond unless we'd kill it and restart it again. It looks like all the time is being spent waiting for I/O in sqlite calls starting from mozStorageConnection.cpp.

In addition to the issue at hand it seems to me that this means that an app using synchronous I/O is effectively able to DDOS the phone. Wouldn't we want to mitigate this in some way?

Comment 16

[Gabriele Svelto [:gsvelto] (PTO)]

I've reproduced the issue again but this time I've captured the SQL statements that seem to be responsible for the slowdown in the hope that they might help solving the problem. The problematic transactions seem to be two with the first one taking most of the time:

BEGIN IMMEDIATE TRANSACTION;
SAVEPOINT savepoint
SELECT data, file_ids FROM object_data WHERE object_store_id = :osid AND key_value >= :lower_key AND key_value <= :upper_key ORDER BY key_value ASC
RELEASE SAVEPOINT savepoint

BEGIN IMMEDIATE TRANSACTION;
SAVEPOINT savepoint
SELECT data, file_ids FROM object_data WHERE object_store_id = :osid AND key_value = :lower_key LIMIT 1
RELEASE SAVEPOINT savepoint
INSERT OR REPLACE INTO object_data (object_store_id, key_value, data, file_ids) VALUES (:osid, :key_value, :data, :file_ids)
DELETE FROM unique_index_data WHERE object_data_id = :object_data_id; DELETE FROM index_data WHERE object_data_id = :object_data_id

In addition to this I'd like to note that even if you allow the transactions to finish during the first run the app remains completely unresponsive. It needs to be killed and restarted for it to work.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Those queries are coming from IndexedDB.

The first one appears to be from a getAll call. The second one is from a .get() call or from a openCursor call I think.

Comment 18

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

IDB doesn't run on the main thread so isn't directly the problem here, but if we're doing heavyweight sql queries on a non-main thread and then other disk IO on the main thread, then the contention could explain the blocking.  But the main-thread IO is still the culprit.

Comment 19

[Gabriele Svelto [:gsvelto] (PTO)]

Profiling and monitoring the behavior shows I/O wait time rising to ~70% during the slow down. Capturing a profile of the Maps and main processes shows the Maps app being mostly idle and the main process spending most of the time in write() syscalls.

Comment 20

[John Ford [:jhford] CET/CEST Berlin Time]

Is there any action to take to get this on v1-train?

Comment 21

[Donovan Preston [:fzzzy]]

I would be mighty surprised if it isn't already, but I will double check to be sure.

Comment 22

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Donovan Preston from comment #21)
> I would be mighty surprised if it isn't already, but I will double check to
> be sure.

Donovan, have you had a chance to check?  We should set status-b2g18 -> fixed if it's fixed.

Comment 23

[Donovan Preston [:fzzzy]]

I just checked, v1-train is indeed using packaged maps, so it is fixed.