#Optimizing startup overhead?

1 messages · Page 1 of 1 (latest)

viscid dune
#

(using: official Dagger action, managed GHA action, dagger cloud caching enabled)
Is there anything that can be done to shave off the connect and initialize time ? Together they can still take around 30-40s just to run a quick action.

Some (bit under a half) of the connect time is pulling the engine image, not sure if GHA provides any way to cache that between managed runner runs. But then "connecting to engine" still takes about 10s. The trace doesn't go any deeper, so not sure where exactly is the time spent. Any options there?

The rest of the time (initialize) seems to be spent on .directory(path: "/src") call after the codegen exec. Not sure if that's all codegen since actual codegen logs are about 2s in total.

wind flicker
#

what SDK are you currently using?

viscid dune
#

DM'd you the trace and it's Go

wind flicker
#

🙏

wind flicker
#

@viscid dune is your Dagger module importing any of your project code at this moment?

viscid dune
#

Importing in what sense? The source directory arg is passing in the whole repo but the repo is just a couple of helm charts. If you mean importing natively in Go, then this dagger Go module only depends on whatever was generated by Dagger + one public Dagger module from my daggerverse (git-files-changed)

wind flicker
wind flicker
#

@viscid dune one last quesiton. What CI runner are you currently using?

viscid dune
#

runs-on: ubuntu-latest (managed GHA)

wind flicker
#

perfect, thx

wind flicker
#

@viscid dune I took a look at your trances and would like to try something tomorrow. Ping me when you're around please 🙏

quiet kayak
#

cc @dusty palm 👆

viscid dune
wind flicker
wind flicker
#

@viscid dune we did some investigations and tomorrow we'll be pushing a release that should improve these initialization times. If you could upgrade tomorrow and re-check if you notice an improve that'd be much appreciated 🙏

viscid dune
#

Sure, will do

viscid dune
#

I've tried to do a bunch of runs, re-running the same commit on 0.12.6 as well as 0.13.0 , don't think I really see any conclusive improvement or difference in my case. But I also noticed it seems like the re-runs were almost alternating between time being spent in initialize vs the function I'm calling (see pics). I've had a look in past traces and found similar examples there, so initialize doesn't actually always take that long (as I initially reported), but usually when initialize is quick, the function is slower and vice-versa, so the overall duration of the run is pretty stable, hovering around ~30s. Perhaps this makes sense, given some semantics of the engine I don't know about?

image.png image.png
wind flicker
viscid dune
wind flicker
viscid dune
#

I'll need to have a better look at the earlier traces to see how the duration actually was over multiple runs. When I started comparing 0.12.6 vs 0.13.0 or 0.13.1 I started noticing that the time is sometimes spent mostly in the function or mostly in init, so practically I can only look at whether the overall runtime improved, which didn't seem so when tested v0.12.6 vs 0.13.1 recently. That being said if the 40 second runs were consistently that long in the past then the 10s improvement is pretty good.

Do you have any explanation of why the time is spent sometime in the init with the function being super fast and sometimes the init is almost instant, but the time is spent in the function call? This is on the same code, just re-running GHA. Might help me interpret the traces better?

Either way I appreciate all the help 🙏

wind flicker
#

the only case where init will be slower is when you modify your pipeline's code as the init phase needs to re-generate your dagger module definitions after your changes in the module source code.

wind flicker
viscid dune
#

Yeah I keep thinking maybe there's something about my module (or the dependency module, also mine) that's invalidating the cache in a pattern I don't understand.

The module is working with a fully deep-cloned git repo in go-git, apart from the repo files. But I can't imagine what could possibly change between two re-runs of the same commit 🤷‍♂️