> Which means that, in order to perform large file operations, we need to go through the dance above multiple times in a loop. And that’s why DJGPP is slow: if the DPMI host has to switch to real mode and back for every system call, the overhead of each system call is significant.
Not as bad as it sounds, because INT 13h (which is the BIOS function that DOS uses to read from disk) was limited to 64k anyway, IDE was limited to 128kB per command (probably never more than 64k on DOS), and disk drive buffers were mostly measured in the kilobytes. Which means that every 64k read involved I/O across the bus, and most likely involved actual spnning rust stuff, all of which makes a protected-mode/real-mode thunk look fast in comparison.
> Which means that, in order to perform large file operations, we need to go through the dance above multiple times in a loop. And that’s why DJGPP is slow: if the DPMI host has to switch to real mode and back for every system call, the overhead of each system call is significant.
Not as bad as it sounds, because INT 13h (which is the BIOS function that DOS uses to read from disk) was limited to 64k anyway, IDE was limited to 128kB per command (probably never more than 64k on DOS), and disk drive buffers were mostly measured in the kilobytes. Which means that every 64k read involved I/O across the bus, and most likely involved actual spnning rust stuff, all of which makes a protected-mode/real-mode thunk look fast in comparison.