:wave: hi! I’m looking for a way to understand clo...
# caching
w
👋 hi! I’m looking for a way to understand clock-time difference of build duration between builds that use remote build cache and those that don’t. I understand that when browsing Build Scan I can read the sum of avoidances of each task, but they of course don’t take parallelization into account. E.g. I have this scan which was a clean build (removed local build cache, and
build
directories) so it took everything from remote build cache (except 1 task). It lasted 2m 3s. From my local experiments I know that clean build without remote build cache takes around 3m. Sum of avoidances is 14m 49s, but is there a way to get the clock-time difference of build (~1m) from build scan?
In other words I want to answer question: “how long the build would take if remote build cache was disabled?”
j
you have 14 workers so is it reasonably accurate to say the delta is
serial savings / nWorkers
?
hmm nevermind, your serial execution factor is really low so that is probably just a coincidence
w
Yeah, if I’m not missing something, one has to take into account tasks dependencies chain - some tasks need to wait for others, and I think it’s crucial for such estimations
v
I guess this can not fully be considered, because tasks can for example do work in parallel, also in parallel to other tasks, if they at execution time use the worker API. Even the current value is just a rough estimate, as it uses the time the task originally needed to produce the cached results which could have been on slower hardware or faster hardware or something else slowing down the build and this state there were more savings than there actually were and so on. Considering the potential parallel execution, especially when you cannot in case of worker API, would probably just produce even less correct estimates. 🤷‍♂️
w
I see, thanks. I understand, modeling such “imaginary” build (“what if build wouldn’t use remote cache”) is not really possible.
Even the current value is just a rough estimate, as it uses the time the task originally needed to produce the cached results which could have been on slower hardware or faster hardware (…)
Good point 👍 In case of my organization, our CI uses slower hardware, and it results in, at first glance, strange results like avoidance value (from using remote cache) being higher than task duration when it is executed on local machine.