Overlay reader & mapper support leads to poor cache hit rate

[vasvf]

In 0.3.3 hitrate was very good

In 0.3.4 it is very poor, no more than 20%. And none for development pods

[polac24]

Can you provide logs from https://github.com/spotify/XCRemoteCache/blob/master/docs/FAQ.md#how-can-i-find-xcremotecache-logs right after the build with a poor hit rate on a consumer side? If you feel that VFS is a problem, can you show (at least redacted) your all-product-headers.yaml file for a target that experiences a cache miss?

[polac24]

@vasvf, do you mind checking if the fix in #82 resolves that? It skips unknown vfsoverlay formats and gives a flag to turn off vfs parsing completely.

[vasvf]

I had 100% hit rate when using the same mac for producer and consumer mode (with local docker as a cache) when even on pre- #82 state. But I'll recheck when using our build node as a producer and come back tomorrow. I'll also check it with #82 fix and come back to you.

[vasvf]

Here are logs without #82. Even "google utilities" does not use produced cache (Producer is remote CI runner) xcrc_log.log

hit_count: 32
miss_count: 83
local_cache_bytes: 477384704
indexing_hit_count: 0
indexing_miss_count: 117

82 also does not fix the problem

xcrc_log2.log

[vasvf]

What I found out. Dependencies list is the same, but! On the remote side in producer mode it has different order. remote_deps.txt

On local side in consumer it is like that local_deps.txt

Remote has other modules' products first, then own sources Local has own sources first, then other modules' products

Maybe there's some kind of path sorting in Dependencies remapper? On remote producer we configured Derived data to be in /Build subfolder of the repo. On local consumer it's just regular Xcode ~/Library/Developer/Xcode/DerivedData path

[polac24]

For your logs I cannot say which target's dependencies you need to verify. I recommend cleaning ~/Library/Caches/XCRemoteCache and run a consumer build and then review all .json metas or (better) find a first cache-miss targets with:

grep -r '3a8bb10f5f612098782b3c49960bded5'  ~/Library/Caches/XCRemoteCache/
grep -r '8f72be307cfddba031894e2cbdaad3a7'  ~/Library/Caches/XCRemoteCache/
grep -r 'b190f31b10f26fe71a70e1327d80ccc1'  ~/Library/Caches/XCRemoteCache/
grep -r '7d3c7bc07fbee59877d8c04553916169'  ~/Library/Caches/XCRemoteCache/
...

Not sure what you mean by dependencies on a local side. Local side takes a list of dependencies from a producer's meta json file. Is it possible that you have old entries in your local cache (~/Library/Caches/XCRemoteCache)?

[vasvf]

GoogleUtilities. It's just as an example. You can see that deps are in different order on consumer side and on producer side.

And it causes Local fingerprint Fingerprint(raw: "7cff0294bd0f064f86a75ecd84e60266", contextSpecific: "dc91ad86c13bf275f968606db18deb90") does not match with remote one 3a8bb10f5f612098782b3c49960bded5.

68214777652657c4a0fbac8a9e170a6c8da87e6e-GoogleUtilities-Debug-iphonesimulator-13A1030d-5c3d912ef6dfef787d7bd5cf647a6d67.json.txt

By "local side" I mean consumer side.

Here's order of deps on producer side:

~/gitlab-runner-project-repo/Build/Products/Debug-iphonesimulator/PromisesObjC/...
~/gitlab-runner-project-repo/Pods/GoogleUtilities/...

Here's order of deps on consumer side:

~/Documents/Project_repo/Pods/GoogleUtilities/...
~/Library/Developer/Xcode/DerivedData/Build/Products/Debug-iphonesimulator/PromisesObjC/...

[polac24]

Nice catch! I misunderstood the "consumer dependencies list" (for a producer it is visible in the meta json file) but I assume you debugged the app and compared this variable: https://github.com/spotify/XCRemoteCache/blob/f086feb005dbadf162affdea99fe8818f5fe9430/Sources/XCRemoteCache/Commands/Prebuild/Prebuild.swift#L60

Your guess about sorting in dependencies remapper was right, we cannot do that on a consumer side.

Hopefully, #85 will resolve that. Would be great if you could verify.

[vasvf]

Yes, that fixed everything! 100% cache hit rate!

hit_count: 114
miss_count: 0
local_cache_bytes: 435597312
indexing_hit_count: 0
indexing_miss_count: 93