If you are a developer using Podman on macOS or Windows, you might have noticed that certain operations, specifically building images with large contexts or loading large image tarballs, can sometimes feel slower compared to native Linux or Docker.

I’ve spent some time investigating this performance gap, and my research led me to a recent master’s thesis, Benchmark Orchestrator for Containerized Workloads. In the Experiments chapter, I utilized custom tooling, developed as part of my thesis, to investigate the problem. This analysis notably highlighted a significant optimization I implemented between Podman v5.4.2 and v5.7.0.

The Problem: The Virtualization Tax

On macOS and Windows, Linux containers don’t run natively. They need to run inside a Linux Virtual Machine (VM).

Historically, when you ran a command like podman load -i my-image.tar, Podman client had to transfer that entire file over a REST API (similar to an HTTP upload) into the VM. This process consumed significant CPU and network resources just to move data across the VM boundary.

The Solution: Don’t Move It, Just Point to It

The solution, the new Local API, changes how the client and server communicate. The Local API enhances performance by avoiding slow network transfers for file sharing. Because the host’s file system is typically already mounted within the VM (enabling volume mounting), the API sends the file’s absolute path instead of its content. This allows the Podman service inside the VM to directly access the data via the mounted file system. If the file is not accessible from within the VM, the system will fall back to the standard file transfer implementation.

The Results: Massive Gains on macOS

The performance impact of this architectural shift is dramatic. According to benchmarks comparing Podman v5.4.2 against v5.7.0 on macOS:

• 89% Faster Image Loading: The “Load Image” scenario dropped from ~56 seconds down to just ~6 seconds.
• 81% Faster Builds: Building an image with a large context directory dropped from ~66 seconds to ~12 seconds.

The complete details of the experiment are outlined in the thesis: https://is.muni.cz/th/pyfi7/?lang=en

A Note on Windows

Interestingly, while this optimization works logically on Windows, the benchmarks showed minimal performance gains there.

Why? While the Local API successfully removed the network transfer overhead, it hit a different bottleneck: the file system translation layer. Windows Subsystem for Linux (WSL) uses 9p mounts to translate NTFS to Linux compatible file systems. The latency of translating these file system calls is currently roughly equivalent to the latency of the old API transfer, masking the benefits of the optimization on Windows for now. Optimization of the file system translation is primarily the responsibility of Microsoft, placing it outside of our control.

Conclusion

For macOS users, the new Local API in Podman significantly improves performance, especially for file intensive operations, bringing them close to native speeds. This enhancement is already applied to tasks like loading images from tar files and transferring build contexts. This engineering approach to the Local API demonstrates how targeted development can effectively overcome the inherent performance challenges of virtualization, with potential for future extension to saving images to tar files and exporting artifact content to the file system.

Bibliography

RODÁK, Jan. Benchmark Orchestrator for Containerized Workloads. Online. Master’s thesis. Brno: Masaryk University, Faculty of Informatics. Available from: https://is.muni.cz/th/pyfi7/.