Performance issues with hundreds of offline packs

[halset]

Platform: iOS
Mapbox SDK version: latest from master

Steps to trigger behavior

1. Create two styles with 500+ small offline packs for each of them
2. Resume the packs, but kill the app before the packs are complete.
3. Resume all the packs on app launch

Expected behavior

Acceptable performance.

Actual behavior

Having lots of offline packs for a small number of styles are very slow for a number of reasons. Here are the main issues I have found with profiling and experimenting.

• getCompletedTileCountAndSize is called for each region. Perhaps it could be called once instead of once pr region? That makes it faster, but still rather slow.
• When gathering status of a non-complete pack/region, getTile and getResource are called. There should instead be similar hasTile and hasResource that would not need to copy (and even decompress) the data out of the database.
• Each pack/region has a small number of similar small resources that are fetched from the database a huge number of times. The most busy small resources should be cached in memory for increased performance.
• OfflineDownload::getStatus() parses the style file for each of the regions.

[halset]

By adding tiles_count and tiles_size to the regions-table, getCompletedTileCountAndSize got a 1 minute and 15 second speedup on an old iPad 2 with 800+ offline regions and around 800MB of tiles.

Do you think adding those fields to the regions table would be okay? Or is it not acceptable to double-store such information?

[halset]

#6691 handle all of the above points except for the repeated parsing of the same style. After #6691, the repeated style parsing are now the biggest cpu time consumer on startup of my app.

[halset]

Updated status.

• hasResource got accepted :) added hasRegionResource when the content are not needed by the caller #6707
• Resource cache not accepted [core] cache offline resources in memory #6739.
• Faster getCompletedTileCountAndSize by adding resources.tiles_{count,size} not accepted. I have isolated the change in a separate branch and added transaction for robustness and use a separate user_version numbering scheme to handle future schema changes from master.
• The repeated parsing of the same style json files are the next bottleneck.

I am using the resource cache and the faster getCompletedTileCountAndSize in my app to get acceptable performance. Hopefully, the future will bring a better solution.

@jfirebaugh mentioned that #4106 with a MultiPolygon could be an alternative to using lots of separate regions. It might work, but my offline regions change in location and number from time to time.

[nitrag]

Thank you for your contributions! Following.

[halset]

I have given up offline packs for my app and moved over to server generated tile archives following the same sqlite schema as cache.db as recommended in #3894. I have added two methods to MGLOfflineStorage that inserts resources and tiles async and given control of the evict to the app according to my suggestion at #7195.

This is working very well for my app. It is now several times faster for the user to download tiles and resources for a predefined area. The huge cpu/io cost of gathering statistics at startup are also gone.

[1ec5]

Now that #11447 has landed, it may be more efficient for you to create one offline pack that covers a multipolygon than to create lots and lots of offline packs, since there’s probably a nontrivial overhead to creating a pack in the first place.

[pedrocruzlopez]

@1ec5 Hi, I'm having performance issues downloading too many offline regions, could you please share some example of the multipolygon approach?