Avoid loading compose info unless needed

[henrinormak]

This improves performance in scenarios where the caller does not rely or need compose in any way.

Anecdotal evidence is from a repository that has 289 test cases, ~260 of which somehow interact with testcontainers. There's enough abstraction between the tests and testcontainers so that not each of the tests hits this slow path, but still, the timing (run on a M3 Pro) shows a clear improvement.

Before - 19.69s, 18.30s, 18.05s, 17.54s, 17.70s - average 18.256s
After - 18.03s, 15.61s, 15.57s, 16.46s, 15.54s - average 16.242s

It's not much, but in all likelihood, depending on the setup, the difference is bigger with more parallel test suites, or situations in which getContainerRuntimeClient is called from different workers/processes more.

[netlify]

✅ Deploy Preview for testcontainers-node ready!

Name	Link
🔨 Latest commit	13f5d03
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-node/deploys/68233af8d465f600086c1538
😎 Deploy Preview	https://deploy-preview-1001--testcontainers-node.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[henrinormak]

What I don't know is how breaking the lack of compose info on the container runtime client is, i.e that's an exposed API from testcontainers that someone could theoretically be depending on.

[henrinormak]

@cristianrgreco any feedback on this? I know that it's a bit out of the left-field (unexpected PR or something), but I've been going after any low-hanging fruit in our CI pipelines to optimize testing and this seemed like a good candidate.

[cristianrgreco]

Hey @henrinormak, apologies for the delay. I've seen the PR but not sure what to do with it yet 😄

I agree the time save is worth it, I just don't like introducing the LazyComposeClient. We only need it because currently we need the version to determine whether to use docker-compose v1 or v2 (and not have to await composeClient everywhere). The thing is, as part of this PR #938, we're dropping support for docker-compose v1. In that PR we still log the version (and so have this performance hit), but it could be as simple as removing it, as done in this PR, 2 line change. I'm tempted to leave this PR and drop the version log in #938. WDYT?

[cristianrgreco]

Superseded by #1012

[henrinormak]

Thanks! I think that makes sense and my main goal was to just remove the time spent on compose if compose is not used.