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

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.

I will work on this in Q1/2013.

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

Tracking based on v1-next performance target.

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?

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.

(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.

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.

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

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

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.

(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?

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