Asamm/matching cache improvements

[menion]

After a lot of tests and benchmarks, where usually performance difference was close to 0, this change makes a major impact!

1. Change in MatchingCacheKey object

The current key object has a few disadvantages

• it is an extra object created for every node/way
• it internally creates a list of filtered tags
• matching in the cache may not be so fast because it always computes a hashcode etc.

All this is solved by the RenderTheme.computeMatchingCacheKey method, which directly computes the Integer based key from necessary parameters without creating any extra object.

2. Increase cache size

This one is a game-changer. The current "way/poi -matchingCache" cache limited to 1024 causes a very often removal and re-adding of many identical items, just because of its size.

My recommended value is 8192. The biggest themes I've tested have around 5 - 6k of cached items in zoom level 12. An increase in the cache size causes a reduction of matchNode and matchWay calls to 10%! Almost no garbage collector calls and amazing performance gain (together with optimization no 1.).

I've also converted cached instructions to RenderInstruction[] (from List) to save a few bytes in memory.

Result

Comparing to the current! master branch performance (so already a little improved), this change brings another reduction of rendering time to 78% (so it is 66% compared to the original code before any optimizations).

With the current devices, 8192 is no problem in terms of memory. I also use a very similar setup in the Locus Map for years!

[devemux86]

@menion thanks for the important improvements and the detailed description!

Change in MatchingCacheKey object

Very nice (also the multiple maps deduplication was improved with hashCode, #1288).

Increase cache size

👍

[devemux86]

I also increased the cache size in VTM (was 512).
mapsforge/vtm#989