Replace per-tile disk cache files with a single blob - #257
GeraldKimmersdorfer wants to merge 2 commits into
Conversation
f329692 to
1b0a161
Compare
|
there are two large issues with this: the memory thing is important, it will cause crashes. I see the problem of slow startup speed, that's also the reason for storing quads. another solution would be to save M tiles in a blob, with M being something like 16 or 64 or something. could be every other zoom level. grouping was too much work back then, so I left it for the future. |
|
Hey, youre welcome. Yes I assumed that the quad idea was implemented for cache and keeping compact texture arrays. I also only implemented it because the loading time bothers me. I didnt know that temporary memory peaks are a concern of yours. I actually had it implemented with incremental file appends which would keep memory low, but would increase processing time (because of multiple io access). Writing the whole blob in-memory first was a concious decision of mine. The same with loading: I was actually thinking about mmap to save one allocation but deemed it as unnecessary complex and overengineered for no measurable gain. [makes you os dependent] (but then again I was purely optimizing speed (on desktop) - not memory efficiency) What I can offer you is to implement the straight forward fix that llm suggested for 1 if you are interested in merging. Otherwise I'd leave it on the webigeo end (for now). |
|
In the long run it would also be possible to have the disk cache independent of the RAM cache, but that would require a bigger refactor that I didnt want to start. |
|
the quad thing was also for performance on GPU. well, I don't know what's your tile limit in ram, but back then I tried to configure it for several hundred mb. doubling that could crash the browser, especially in mobile. and yes, disk cache should be larger than memory cache. that's also only a quick solution. the disk cache shouldn't be read back in the beginning as a whole (only on demand). I think that this would be the actual fix. mmap would be another, but platform dependent and in the long run probably better: https://chatgpt.com/share/6ab512d5-ec94-83eb-921e-f7c93c2c2a4d?ogimg=plain as is, I wouldn't merge. temporary memory peaks are a deal breaker:) |
|
Okay fair enough, then I'll close the pull request for now. For snow I'll probably have 5 different tile sources in total (normals, snow-roughness, clouds, geometry, ortho) - maybe even more if i also implement the heuristic based on sun exposure. (and then we'll see if i can merge some in the end :|) Thats the reason I really want to optimize the pipeline right now though. If I run into memory issues down the line I'll maybe revisit this issue - then we can still open it again. |
2 participants
This PR replaces the one-file-per-tile approach with one binary blob per tile source which is expanded whenever we need to persist new tiles. This will introduce dead bytes inside the blob though - to that end when the amount of dead bytes succeed the amount of alive bytes multiplied with an adjustable factor - this binary blob is compacted (basically by completely recreating it)
OS file access is kept to an absolut minimum which ends up in a significant speedup for write (in my measurement I ended up with a speedup of x9 with the blob based approach needing an average of 40ms where the old, per file approach averaged at 339ms). An even bigger gain was observed for read of the tile cache - especially with a cold os-cache. In one instance it took about 7 seconds to initially load the cache from file. This number seems to be around 240ms on my machine now and its mostly independent from the number of tiles. (similar result for quads vs tiles)
Compacting a cache with 20.000 tiles took about 500ms on my machine. However this is an even that rarely occurs - and like the 10s writes runs on the scheduler thread - so no frame is stalled.
tested on Windows 10 with an AMD Ryzen-9 3900X 12-Core, 3800 Mhz, MSVC, release build