Richard Eckart de Castilho

Still, 10 seconds additional delay simply when trying to open a bndrun file in the editor is noticeable by the user... personally, I'd vote for keeping the deferral in.

Well, if I look at my logpoint output, I see lots of times in the 5ms-10ms range for calculating the hash sums. As I said before, I have some files...

Here's a more accurate measurement. I took the first 1000 timings of SHA256 calculations from the run I logged ealier. These sum up to 17847 ms - that's ~17ms on...

Here are the timings ;) batch of 1000, times in ms. The longest in this batch was 1039ms, but I have seen also longer calculations in the full run. [timings.log.gz](https://github.com/bndtools/bnd/files/9530014/timings.log.gz)

So if we assume 10ms per SHA256 calculation and we had 1004 cache misses in the above calculation, that would be 10 seconds with the deferral in place. If we...

Ok, what we do not know is if the calls saved by the deferral would have been cache hits - in that case, the deferral would be indeed pointless.

So, new numbers from my little real-world scenario here: * 1010 - so many SHA256 for unique paths made it to the cache * 1139 - for so many unique...

@bjhargrave thanks :) I'm building and trying it.

Seems like the cache might not be used in all access paths to the SHA256. When I try opening a `.bndrun` file after starting Eclipse, it takes very long with...

When I attach a debugger with a log point in `SHA256.digest(File)`, I can see that after a short time the method has already been called 9 times for the same...