Closed Bug 817154 Opened 12 years ago Closed 12 years ago

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

Categories

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

defect

Tracking

(blocking-basecamp:-, b2g18+ fixed)

RESOLVED FIXED
blocking-basecamp -
Tracking Status
b2g18 + fixed

People

(Reporter: cjones, Assigned: fzzzy)

References

Details

(Keywords: perf, Whiteboard: UX-P1, interaction, BerlinWW)

Attachments

(1 file)

Instead of going through douchebag appcache. The current first-run experience of maps is atrocious.
Whiteboard: [3rd-party-preloaded-apps]
Whiteboard: [3rd-party-preloaded-apps]
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.
blocking-basecamp: --- → ?
Whiteboard: UX-P?
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?
For all our sakes, I hope so :/.
heh
Let us know when a decision related to feasability and stability has taken and renominate if needed
blocking-basecamp: ? → -
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.
blocking-basecamp: - → ?
Triage: BB-, P4 - first run (only) performance issue tracking-b2g18+
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Priority: -- → P4
Fabrice, do the pre-packaged external-apps get installed into /data on firstrun? Or must they continue to be updated through /system updates?
Flags: needinfo?(fabrice)
Summary: Package maps app and deliver that in build → Launching the maps app results in the phone being unresponsive for seconds at a time over a period of minutes
Preloaded 3rd party apps are installed on /data, and can be updated "normally", without a full gecko+gaia update.
Flags: needinfo?(fabrice)
Beautiful. To be clear, this applies to packaged apps too right?
(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.
Donovan, any progress? I would approve this so hard ... ;)
Hah, I wish, I really haven't had time to get to this, sorry. I'll see if I can find some time.
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.
Whiteboard: UX-P? → UX-P1, interaction
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?
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.
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.
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.
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.
Whiteboard: UX-P1, interaction → UX-P1, interaction, BerlinWW
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: b2g-maps
Is there any action to take to get this on v1-train?
I would be mighty surprised if it isn't already, but I will double check to be sure.
(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.
Flags: needinfo?(dpreston)
I just checked, v1-train is indeed using packaged maps, so it is fixed.
Flags: needinfo?(dpreston)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: