This is an interesting snap - it looks like running the python code directly is still significantly faster than the snap even when I use “snap try --devmode ./prime”. I did an strace -c of the snap and noticed it is performing a lot of syscalls (lseek,mmap) - this indicates seccomp overhead. And indeed - when switch from “@complain” mode in the seccomp devmode profile to “@unrestricted” the gap goes away.
In summary - this needs closer investigation if we can do anything about our bpf profile writing or if the kernel can be optimized so that very syscall heavy apps (like this one) get less performance impact.
Fwiw - the numbers I have on my machine with a random example memory image is: ~14s when running directly from the virtualenv and when using @unrestricted in the seccomp profile and ~20s with the regular snap. I see about 1134304 syscalls in total, mostly lseek/read (from strace -c).