Is there a difference between the physical machine and the Docker image environment in a container when using LoadAssembly to load a DLL?

[SFWqiudong]

Dear dotnet team and guys, have you ever encountered a situation where loading assemblies in a container environment is slower than in an actual physical machine?
I attempt to write a simple benchmark to load assemblies (net6.0) and run it both in physical machine and k8s (docker environment
) To load lots of dll for test. The assemblies loaded in both environments are consistent. And both have similar computer configurations (with the container having an advantage in the number of cores and amount of memory, and both using SSDs).
Benchmark code is here (very simple)

foreach (var file in Directory.GetFiles(directoryPath, "*.*", SearchOption.AllDirectories))
  {
      try
      {
          Assembly.LoadFile(file);
          count++;
          Console.WriteLine($"Loaded: {file}");
      }
      catch (Exception ex)
      {
          Console.WriteLine($"Error loading {file}: {ex.Message}");
      }
}

I have come to some conclusions:

1. On average, the loading speed in containers is slower than in a physical machine environment.
2. The first time I tried running the benchmark on a physical machine, it was very slow (comparable to the speed in the container), but on subsequent runs, the speed increased and remained consistent. But in container, all test results remained consistent.

It seems like LoadAssembly has a mechanism similar to caching loaded assembly? Or could there be other reasons that might explain this difference?

[huoyaoyuan]

The first time I tried running the benchmark on a physical machine

Do you mean that a new process is started for every run?

If so, I believe is an OS behavior. There can be OS file cache, anti-virus filters, or filesystem virtualization handled by OS.

[huoyaoyuan]

It depends a lot on your actual configuration. Maybe it's caused by virtualization or something.
The long delay on first run of physical machine looks like antivirus.

[SFWqiudong]

The testing environment of the physical machine I utilized might be quite distinctive, as I didn't encounter any antivirus notifications during its operation. I'll make sure to verify this further.
Additionally, regarding the initial run on the physical machine appearing akin to an antivirus, could this discrepancy, as opposed to being attributed to cache differences, be simply due to the fact that AssemblyLoad operates with less efficiency in a virtual environment compared to a physical one?

[huoyaoyuan]

I'm not aware of any syscall made by Assembly.LoadFile other than opening and reading the file.

[Clockwork-Muse]

Most important first question - how were you performing the container runs?

Because if you were doing something like docker run --rm .... , or starting a new pod/etc, each time, you'd get a new fresh filesystem/os state each time. So even if it did cache certain things locally, they'd go poof after the test finished.

[SFWqiudong]

I conducted the test by logging into the pod, and during the testing period, all pods remained alive.