Multiple maintenance() calls possibly impacting performance

[pasniak]

Why, when scrolling around I get multiple maintenance() calls which seem to slow down the display (see screenshots)? Maybe the should be compacted into periodic call?

    public void maintenance() {
        this.garbageCollection();
        this.mPreCache.fill();
    }

Issue Type

[x] Question
[ ] Bug
[ ] Improvement
[ ] Build system related
[x] Performance
[ ] Documentation

Description and/or steps/code to reproduce the problem

[pasniak]

We probably can close this. My long[] mTileIndices (in MapTileList) is 301 elems long and the loop in contains is slow in Debug mode. Is is fast in Release.

[monsieurtanuki]

@pasniak Looking back at the code there might be a couple of possible (but light) improvements.
Let me see...

[monsieurtanuki]

First thing: be sure that you pulled the latest version of master. I recently removed a duplicated code execution regarding protectDisplayedTilesForCache in DefaultOverlayManager.onDraw.

A solution would be to increase the capacity using MapTileCache.ensureCapacity (up to 301 in your case?). With a bigger capacity, we don't have to check which tiles we can remove from the cache (with a time-consuming O(n) contains method) because we have enough space (cf. MapTileCache.garbageCollection).

Another solution would be to use smaller protected tile sets (cf. MapTileProviderBasic's constructor: getTileCache().getProtectedTileComputers()). With smaller sets, it's faster to compute the sets and it's faster to check which tiles the sets contain (cf. MapTileCache.garbageCollection and MapTileCache.shouldKeepTile)

I'm also working on the following idea: adding a message in the log. Something like "You'd have better performances with a tile cache capacity of xxx, or with smaller protected-cache-tile sets".

[pasniak]

I am trying to get my head around the ensureCapacity... (where to set it? do you have an example?)

[monsieurtanuki]

Something like getTileCache().ensureCapacity(50); in MapTileProviderBasic.

But I'm actually PR'ing something called setAutoEnsureCapacity, in order to automatically upgrade the cache capacity to the level of convenience specified by getTileCache().getProtectedTileComputers().

[pasniak]

👍 the computers are beyond my pay grade...

[monsieurtanuki]

Just PR'ed #1131

[monsieurtanuki]

Btw the concept of protected tile is not that hard to understand - I assume.

The idea is to say "OK we currently display those tiles, but there's a good chance we'll soon need tiles for zooms +-1 or tiles at the border".
That explains this code in MapTileProviderBasic:

getTileCache().getProtectedTileComputers().add(new MapTileListZoomComputer(-1)); // zoom -1
getTileCache().getProtectedTileComputers().add(new MapTileListZoomComputer(1)); // zoom +1
getTileCache().getProtectedTileComputers().add(new MapTileListBorderComputer(1, false)); // border of 1 around, and just the border

And what happens is that during the maintenance we do basically 2 things:

1. ensure that those "protected" tiles are not removed from the memory cache, as we assume they will probably very soon be important when zooming/panning - there's a trade between low memory management and reactivity
2. asynchronously pre-cache the "protected" tiles into the memory cache, from a limited list of providers (cf. getTileCache().getPreCache().addProvider)

[monsieurtanuki]

The next thing I would like to fix is the "is that tile in the protected list?" algorithm.
Currently, the map tile lists are just long[], which can only be processed iteratively.
The bigger the list, the slower the contains check. Which happens during the UI thread...
The solution would be to consider a sort of zoom+rectangle container instead of a mere list.
I'll think about it...

[monsieurtanuki]

The solution would be to consider a sort of zoom+rectangle container instead of a mere list.

Done in #1131
The name is MapTileArea

[monsieurtanuki]

Just merged #1131.
@pasniak Feel like testing it?

[monsieurtanuki]

@pasniak ping
The fix is available in the new 6.0.3 release.