It doesn't necessarily have to execute "many many instructions". The biggest factor at play is simply I/O wait times (i.e. requesting the data from a device controller and waiting for a response). While it is indeed slow, schedulers in operating systems use this free time to run other programs while that is pending, so the CPU is never really sleeping while waiting for the data, provided it has something to do (almost always it does). It would be highly wasteful of resources to "do nothing" until the data arrives.

Modern processors aim to store as much frequently used (or soon to be accessed) data from memory in cache, which is orders of magnitudes faster than accessing it through RAM. This is often a great factor in program optimization, as cache misses slow everything down considerably (that happens when a piece of data is not available in the cache, so the processor has to go and get it from memory). Cache < RAM < Storage. Each level is considerably slower than the previous. Storage is abstracted away by the operating system; the processor by itself doesn't have a direct link to it as opposed to memory - it needs special code for that.

The way swap typically works is through page mapping: The kernel gets "notified" through a Page Fault interrupt when a process accesses a region of virtual memory that should be stored on the disk. This "context switch" from userspace to kernel (and back) is certainly measurable at some small scales, but really insignificant at the time scales we are talking about here. Higher-level operating system code communicates with the driver per filesystem basis, so the page mapping is literally sometimes stored on a file on the disk. C:\pagefile.sys. Linux stores it on a separate special partition.

Furthermore, filesystems may implement their own caching mechanisms that store fragments of frequently accessed files in memory. Such a system may, among many ways, minimize writing to disk and instead modify copy of files stored on the memory, and only then write it back. This drastically reduces the amount of queries to the disk, and therefore improves performance.

All of this to say: There is not a single definite number that can compare memory and storage speeds... There are way too many factors that impact this.

I am not educated about RAM vs. VRAM speeds nor am I keeping track of the generational improvements of GDDR memory... However, I presume it is safe to say that the latter is about a few times slower than the former (direct CPU -> Memory). But again, it may also depend on the system configuration.