As you are speaking of it, I signifially improved to SAS memory-interface to the CCPU yesterday, because scrolling was really slow on the console as soon as the emulated EGA/VGA kicked in.
There is a smart logic for console mode in NTVDM: If you just do normal text I/O via the INT 21h DOS-functions or do just teletype write, the NTVDM doesn't do any video adapter emulation and just flushes out anything to console. So you have the advantage of fast output and console redirection. As soon as your application does any cursor positioning and such (i.e. via INT 10h), it switches the console over to video adapter emuation (which is slow) and stays that way until you close the console.
The video adapter emulation does a lot of I/O on the virtual video buffer and therefore slows down everything.
Now my impovement to the SAS-routines at least allows block-wise memory moving which significally improves video output performance ov the 1-byte based read/write loops it originally uses.
I will provide a patch the next days on github that patches in the improved SAS-interface, stay tuned.
However don't expect too much from the C_VIDC emulation of NTVDM. Remember that the original NTVDM doesn't do any console graphics but instead always switches to fullscreen (X86GFX) as soon as there is graphic output, because it can take advantage of the fact that it can directly write to the VGA video card (via the miniport driver) which is blazing fast.
But Microsoft introduced a new display driver model with Windows 7 (WDDM as opposed to the old XPDM), which lacks the possibility to use the VGA card directly (but is better for fast output rendering). This causes the problem when you get an error message when you try to switch a console window to fullscreen with ALT+RETURN.
In Windows 7, the kernel supported both display driver models, so you were able to switch between them. By simply disabling the WDDM display driver, you were switched back to Standard VGA XPDM driver semalessly and were able to use NTVDM like you were used to from XP. There are even patches out there, that automated this for you.
Unfortunately, with Windows 8, the support for XPDDM was gone for good and so was NTVDM's ability to use fast, direct video output.
However the Windows console has always featured a console graphics buffer, as it was also needed for non-X86 builds of NTVDM. It has a bug that must be fixed (which the NTVDMx64 loader does for you). So in Alpha/MIPS/PPC builds, an emulated video card was used and fortunately the sourcecode contained the C_VIDC c-implementation of it. Insignia emulated a full Video controller, but not in neat C-code, as one would expect, but they used something called J-code, which seems to be some intermediate code that was then compiled to unreadable, ugly C-code. It seems to work, but it's not very fast.
There also is the flavor of A_VIDC, which would specify an interface to an Assembler-based video card emulation. As far as my analysis has shown, for non-X86 builds, the didnt use the C_VIDC but maybe the A_VIDC. However, we don't have any sources for it, so our only option to get rid of the slow C_VIDC would be to write our own, faster implementation, if possible with the given architecture.
So, long story short: NTVDM's video card emulation sucks... Maybe someone wants to have a look at it?
Regarding the CPU load, there already is a nice trick on the original NTVDM to keep CPU load low, I think most of the people here know it: https://forum.qbasic.at/viewtopic.php?t=2172
Basically, these are TSRs that hook the timer interrupt and release the timeslice to the host CPU on idling. They also work on NTVDMx64. The original download seems to be unavailable, here is a mirror: http://dose.0wnz.at/auslast.zip
Have a nice DOS...