822833 - AppCache does blocking disk I/O on the mainthread

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect, P2)

Description

[Philipp von Weitershausen [:philikon]]

Updating a hosted app via app cache can massively degrade B2G's performance. The big offender is nsOfflineCacheDevice, in particular nsOfflineCacheDevice::UpdateEntrySize() [1] which is executed several times per downloaded file and each time performs blocking disk I/O on the mainthread.

See bug 813765 for an extensive discussion.

[1] https://mxr.mozilla.org/mozilla-central/source/netwerk/cache/nsDiskCacheDeviceSQL.cpp#979

Comment 1

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

This sucks, but fixing this is simply too big of a change too late in the game. We've always known that the appcache is sucky performance-wise, and while that sucks, trying to fix this will be too high risk.

We need to find workarounds or simply live with poor performance.

Comment 2

[Honza Bambas (:mayhemer)]

I will work on this in Q1/2013.

Comment 3

[Jason Smith [:jsmith]]

Tracking nomination mainly cause we'll want to eventually fix this, even if it's not for v1.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking based on v1-next performance target.

Comment 5

[Dietrich Ayala (:dietrich)]

Jonas, is the level of change too take on the 1.x branch even? Or push to 2.0? Or forget it in favor of appcache-successor?

Comment 6

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

I think focusing on the appcache successor is likely better use of our time. Even if we fixed the performance problems in our current implementation, people would still not want to use it given how bad the spec is.

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Jonas Sicking (:sicking) from comment #6)
> I think focusing on the appcache successor is likely better use of our time.
> Even if we fixed the performance problems in our current implementation,
> people would still not want to use it given how bad the spec is.

Yes, but the current B2G as well as we can predict a first official release is about to use the current appcache spec and our implementation.

It is considered a serious perf issue.

I will spend some little time to just look if a quick solution would be avail.

Comment 8

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

If you can find a simple-ish way to significantly reduce the amount of sync IO blocking on the main thread, then I definitely think that that would be worth taking.

Comment 9

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

(One of those sources of jank we don't like to discuss.)

Comment 10

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

One of the things we don't like to talk about.

Comment 11

[Florian Bender]

Even if there is a successor, I'll guess a substantial amount will still use the old one (at least short- to mid-term). Thus this should be fixed anyway. 

And if not v1, then please try to land this in v1.x.

Comment 12

[Jean Gong :jgong]

(In reply to Jonas Sicking (:sicking) from comment #6)
> I think focusing on the appcache successor is likely better use of our time.
> Even if we fixed the performance problems in our current implementation,
> people would still not want to use it given how bad the spec is.

Jonas, can you find the bug # for appcache successor that you are referring to?

Comment 13

[Josh Matthews [:jdm]]

The successor API is ServiceWorkers, and bug 982725 tracks the Cache sub-API in particular.