building a merkle tree should not be much more expensive than building a list if implemented correctly. Does this still hold true compared to the comment mentioned here: https://github.com/bazelbuild/bazel/pull/7583#issuecomment-468568192? I don't know. You'd have to benchmark the current merkle tree implementation against a list based approach I guess. I'd expect the list based approach to still be faster but I am not sure whether it's by a lot.
remote/performance: don't construct a merkle tree for remote caching
Remote caching doesn't benefit from constructing a merkle. Some users reported significant performance overheads from constructing the merkle tree. We might just want to compute the hash of the list of input file hashes instead.

cc: @benjaminp
src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
diff --git a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
index 4ef09ad268f260..2da0cc1203d446 100644
--- a/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
+++ b/src/main/java/com/google/devtools/build/lib/remote/RemoteSpawnCache.java
@@ -90,7 +90,7 @@ final class RemoteSpawnCache implements SpawnCache {
   @Override
   public CacheHandle lookup(Spawn spawn, SpawnExecutionContext context)
       throws InterruptedException, IOException, ExecException {
-    if (!Spawns.mayBeCached(spawn)) {
+    if (!Spawns.mayBeCached(spawn) || !Spawns.mayBeExecutedRemotely(spawn)) {
       return SpawnCache.NO_RESULT_NO_STORE;
     }
     boolean checkCache = options.remoteAcceptCached;
