More efficient cache system

[Sworddragon]

I have made a few tests with the cache system:

START=$(date +%s) && c10t -w /srv/minecraft/world -o world.png -R 100 && END=$(date +%s) && echo $(($END-$START))

Without the cache 30 seconds were needed.

START=$(date +%s) && c10t -w /srv/minecraft/world -o world.png -R 100 --cache-key='key' && END=$(date +%s) && echo $(($END-$START))

There was no cache so the first run needed 92 seconds.

START=$(date +%s) && c10t -w /srv/minecraft/world -o world.png -R 100 --cache-key='key' && END=$(date +%s) && echo $(($END-$START))

With the cache (cache_hits: 24074/24074) only 25 seconds were needed.

The cache can be only used on the same options because of the current behaviour of --cache-key. A user need to look at the worldmap 14 times with the same options until he gains benefits from the cache. There are 3 things that could be enhanced:

1. Reading from the cache seems to be very slow. In my case the cache directory contains 24074 files and 4162 directories. Maybe accessing and checking these files is the problem here. A solution could be to find a way to use less files (for example a simple database).
2. Writing the cache files needs a lot of time too. Maybe one big cache file could solve this problem too.
3. --cache-dir needs for every option an own unique key. But theoretically options like -R doesn't need this. There could be an option which is generating automatically a cache key using only the options that are really needed.

[uap-universe]

Are you testing on a VPS? Please consider that you're sharing IO throughput with many others then. Please also consider, that your test case is not suitable for evaluating cache efficiency. 25 sec vs 30 sec is not very significant. But you are right however, as my test case will show.

My results with the following commands on a VPS CentOS x64 with 2x1,5 Ghz:

./c10t -z -r 90 -M 2048 --center 15,43 -R 196 -w /opt/minecraft/world --split="256 512 1024 2048" --split-base=512 -o ./work/tiles/day.%d.%d.%d.png --write-json=./work/day.json --cache-dir cache/area01 --cache-key gmap-day
./c10t -z -r 90 -M 2048 -n --center 15,43 -R 196 -w /opt/minecraft/world --split="256 512 1024 2048" --split-base=512 -o ./work/tiles/night.%d.%d.%d.png --write-json=./work/night.json --cache-dir cache/area01 --cache-key gmap-night

Memory load on rendering: 814 Megabytes

With caching:
First run: 40 to 45 minutes. Subsequent run (one day difference): 25 to 30 minutes
Cache size: 5 Gigabytes and about 120,000 files

Without caching:
7 minutes

You see, that the caching is only effective on very very very large maps and with a very very very good hard drive and very very very good disk io throughput.

Your first and second idea are the way on how to improve this I think. 120,000 files (especially without SSD) simply can't be fast.

[Sworddragon]

Are you testing on a VPS?

I have tested this on my local system. The attributes of the directory was modified with "chattr +A -j /tmp/no-journal" to increase the performance. The disk was a common mechanical hard drive.

[Sworddragon]

On testing this again I'm noticing that using the --cache-key option is much slower even if the cache already exists. I think the main problem could really be the massive amount of small files being created causing a high I/O overhead.