> because merely decompressing the packages is very slow Is this because the guest code is making syscalls that context-switch, and that imposes a lot of inter

> because merely decompressing the packages is very slow Is this because the guest code is making syscalls that context-switch, and that imposes a lot of interpretation overhead; or is it mostly because the emulator's disk driver maps calls to write to disk X directly to host IO against the file representing disk X, such that O(N) emulated IOPS translate to O(N) host IOPS? If it's the latter, then this sounds like it'd be the same problem that Docker.app dealt with on macOS: some guest apps do IO in a single-threaded + serially-dependent (write, then read back, then write back, then read back...) manner, and so they degrade basically quadratically when there's any kind of IO-syscall latency. (You can see a similar effect if you run e.g. `apt-get install` within an NFS-mounted chroot.) Alternately, if the emulator's disk driver mmap(2)s a host file to serve as the emulated disk—then large-batch streaming writes from the guest would become large piles of dirty pages in need of flushing; and large-batch streaming reads would become large piles of page faults. And because the guest workload is opaque to the hypervisor, it wouldn't be able to use madvise(2) or the like to tell the iPadOS kernel how to predict/coalesce these. If either of these is the problem with UTM SE's emulated-block-device IO perf, I'd be curious how much better emulation of IO-intensive operations would perform if they reimplemented the block-device driver as a userland large-block-size page file — i.e. what an RDBMS calls a buffer pool. (AFAIK this is already a best-practice for hypervisors that work with expected-high-latency disks. If you tell VMWare ESXi/vSphere to use an iSCSI storage adapter, then that storage adapter is going to do client-side in-memory caching of the iSCSI target at some larger-than-one-disk-sector granularity.)