Today I feel like I've spent 90% of my

[mellow gull]

😆 When I start on a fresh engine or with new modules or new images, I had a feeling that 0.9.x SDK Dagger (go run... or dagger run go run... might have been a lot faster, but so far I'm not seeing that.

I have a module where I took an old golang example in the 0.9 docs and broke it into 3 modules.
https://daggerverse.dev/mod/github.com/jpadams/daggerverse/drupalTest@2819ab2ad05bf862531c1d2d82380b2ac14bd89e
drupalTest, drupal, and mariaDB
https://archive.docs.dagger.io/0.9/cookbook#use-transient-database-service-for-application-tests

When I run them head to head, after the first run, they are comparable in runtime.

dagger -m  call run  0.53s user 0.33s system 12% cpu 6.821 total
dagger -m  call run  0.54s user 0.37s system 12% cpu 7.332 total

dagger run go run main.go  0.98s user 0.56s system 21% cpu 7.237 total
go run main.go  0.56s user 0.55s system 14% cpu 7.365 total

[zealous pasture]

It was making me wonder if Dagger verse can provide a module cache

[mellow gull]

Love that idea cc @oak belfry @proud bough

[proud bough]

Yes, that's the plan. We're going to leverage our existing distributed cache infrastructure (with buckets in 26 cloud regions including across AWS, GCP, Cloudflare), to provide a global module cache. Similar to Cachix in the Nix ecosystem. The only reason we haven't built it yet, is time and priorities. It will come 🙂

[oak belfry]

@zealous pasture is your repo using dagger public? I highly suspect there's something else going on that's causing excessive cache invalidations (which would also mean that a remote module cache wouldn't actually help that much). I'm sure I can find/create other examples, but if your repo happens to be public it sounds like it would be a good real-world stress test to use for finding/fixing these sort of problems 😄

[proud bough]

Also, would it help to share Dagger Cloud run links so we can look at the time breakdown @oak belfry ?

[oak belfry]

Yes absolutely, I'll take that if it's available too 🙂