#Performance Regression in withMountedDirectory Between Dagger 0.18.15 and 0.19.6 ?

1 messages · Page 1 of 1 (latest)

round dome
#

Hi Dagger team,

We’ve observed a significant performance regression when upgrading from Dagger 0.18.15 to 0.19.6.

Context

We have a Dagger JavaScript module that depends on a Dagger SonarQube module.
The issue occurs when the SonarQube module mounts a directory that has already been mounted earlier in the calling JavaScript module.

This workflow works correctly and efficiently in 0.18.15, but becomes extremely slow in 0.19.6, with no changes on our side.

Observed Behavior

Dagger 0.18.15
Trace: https://dagger.cloud/betclicgroup/traces/1bb96d89314f27791462ecf799412144?listen=3524c10f06c65f24&listen=5b14eaf8a22cf805&listen=88d14addafc8c574
withMountedDirectory(path: "/usr/src", source: Container.directory(path: "/app"), owner: "1000:1000")
→ ~4 seconds

Dagger 0.19.6
Trace: https://dagger.cloud/betclicgroup/traces/6bf2ae0d13c6a20f87a7692bfc61e1aa?listen=0e1d3afb33490496&listen=a0d36a904c6e9103&listen=5d50b2ac81e9e302
Same call:
withMountedDirectory(path: "/usr/src", source: Container.directory(path: "/app"), owner: "1000:1000")
→ ~3 minutes 46 seconds. Additionally, in 0.19.6 Dagger creates a directory during this step — something that does not happen in 0.18.15.

Questions
1. Is there any change in the behavior of withMountedDirectory or how Dagger handles directory reuse between modules?
2. Is there a recommended workaround?

neon raven
#

Hi thanks for the traces 🙏

#

Taking a look ! We've lazified the typescript SDK so it's possible that this step pays the price of something present earlier in the traces, checking rn

neon raven
#

Hi, I suspect there's a recursive regression that occured when porting the ownership of the dir. I've tested locally: between a withMountedDirectory with owner and without, there's a 36x speed difference (which, I think, is due to a not-smart-yet implementation [new O(n) syscalls on 5000 files)], in order to go fast

#

will confirm tomorrow

neon raven
#

I think I have the fix locally, pushing it as a pending PR tomorrow

neon raven