7 ms·

The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scr

The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.

izacus 8y ago
Is that true for other UIs like conemu?
- oldgradstudent 8y ago
  Good question. The article says that > Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would! > For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!! I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
  - laumars 8y ago
    That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows just jumps over that STDIN read request and ploughs through the rest of the program. I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code. As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.
    - codetrotter 8y ago
      Is your shell on github?
      - laumars 8y ago
        Indeed. https://github.com/lmorg/murex https://github.com/lmorg/murex However I'd still recommend WSL or Powershell over my shell for Windows use as I haven't invested an great amount of time on the Windows port (and certainly haven't used nor tested it extensively on Windows like I do on Linux and FreeBSD). Though at some point - probably after I've finished documenting the thing - I do plan to go back and revisit the Windows port.
    - JdeBP 8y ago
      Actually, the part that you have addressed is half the story. I wrote about both halves a couple of decades ago. * http://jdebp.info./FGA/capture-console-win32.html http://jdebp.info./FGA/capture-console-win32.html
      - laumars 8y ago
        Interesting read. Thank you. I wonder how many programs are still using low level access these days given that's more a throw over from the DOS days and most languages will have proper frameworks for reading and writing from the NT console. del et al being obvious exceptions because they're just cmd.exe builtins. Unfortunately I don't have a Windows system to test that assumption but when I think about when I last did my testing, that was only against the cmd.exe builtins so it's possible this bug I was experiencing isn't as widespread as I assumed
GordonS 8y ago
I regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?
- ShinTakuya 8y ago
  The terminals you use in Linux must either be painfully slow or you must be very insensitive to latency issues because the latency on Windows console is really high. When I type something I expect it to appear immediately (<10ms), not in 20-50ms. I'm just guessing the timings here though but the point is that there's definitely a difference. A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.
  - deleted 8y ago
    [deleted]
  - yoz-y 8y ago
    Afaik, 10ms is not achievable nowadays, unless you use a very old computer. https://danluu.com/input-lag/ https://danluu.com/input-lag/
    - userbinator 8y ago
      I'd be curious to see the original IBM PC/XT/AT tested too. I guess it would be near the low end of the list too. Also, the last entry in the list provides another reason why Lisp machines never became popular --- 300ms of input lag! That's definitely in unusable territory, especially when other machines of the time were almost an order of magnitude faster.
      - lispm 8y ago
        If you look at the table you'll see that the 3620 from Symbolics in 1986 was an entirely different system. It had a megapixel bitmap-only screen as a separate console (which had mouse, keyboard, serial and an audio interface) with console cables often of 30 meters. The refrigerator size machines often would be running in some machine room and the console would be used in some office room. The console was handled by a separate Front End Processor with a communication protocol over the console cable. An entirely different technology for a different setup. Later Symbolics Lisp machines used different technology for the graphics system, but basically the same console setup. See here for some more info about the 3620: http://lispm.de/3620/3620.html http://lispm.de/3620/3620.html
Const-me 8y ago
I’ve just run “tree /f” from the root of my drive. It printed huge amounts of text but the scrolling remained instant. I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.
mwcampbell 8y ago
Are you using a high-DPI display? In my experience, scrolling in the console is much slower on a high-DPI display.
- oldgradstudent 8y ago
  Yes, but I use HiDPI displays on Linux and macOS as well.
zadjii 8y ago
I would agree that our perf isn't the best. Almost all of that comes down to our rendering stack - something like 90% of our CPU time is spent rendering the window. This is because at the moment we're stuck with GDI, and IIRC we have to kernel-thunk every row of text we render. It's not a great situation. Stay tuned for updates in this area though. Improving this experience is one of our top priorities.
- delfinom 8y ago
  GDI?! Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)
  - bitcrazed 8y ago
    Hi. Windows Console PM, and @zadjii's whipping boy here :) LOL :) Nice idea - though it turns out that this won't help. Don't ask me why we know this ;) We DO, however, (as @zadjii indicates above) have plans afoot to considerably improve Console's text rendering. Also note that scrolling speed is actually not a good measure of rendering perf! Why? Because at most, scrolling should max-out at around one vertical page every 1/60 of a second. Any more than that and the text tears. This may or may not be an issue for some, but tearing the text upsets people who're visually looking for a particular text layout-pattern which might get discarded if the Console scrolls faster than one page per refresh. This said, yes, we're gonna get faster with less CPU ;)

The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.

izacus 8y ago

Is that true for other UIs like conemu?

oldgradstudent 8y ago
Good question. The article says that > Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would! > For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!! I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
- laumars 8y ago
  That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows just jumps over that STDIN read request and ploughs through the rest of the program. I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code. As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.
  - codetrotter 8y ago
    Is your shell on github?
    - laumars 8y ago
      Indeed. https://github.com/lmorg/murex https://github.com/lmorg/murex However I'd still recommend WSL or Powershell over my shell for Windows use as I haven't invested an great amount of time on the Windows port (and certainly haven't used nor tested it extensively on Windows like I do on Linux and FreeBSD). Though at some point - probably after I've finished documenting the thing - I do plan to go back and revisit the Windows port.
  - JdeBP 8y ago
    Actually, the part that you have addressed is half the story. I wrote about both halves a couple of decades ago. * http://jdebp.info./FGA/capture-console-win32.html http://jdebp.info./FGA/capture-console-win32.html
    - laumars 8y ago
      Interesting read. Thank you. I wonder how many programs are still using low level access these days given that's more a throw over from the DOS days and most languages will have proper frameworks for reading and writing from the NT console. del et al being obvious exceptions because they're just cmd.exe builtins. Unfortunately I don't have a Windows system to test that assumption but when I think about when I last did my testing, that was only against the cmd.exe builtins so it's possible this bug I was experiencing isn't as widespread as I assumed

GordonS 8y ago

I regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?

ShinTakuya 8y ago
The terminals you use in Linux must either be painfully slow or you must be very insensitive to latency issues because the latency on Windows console is really high. When I type something I expect it to appear immediately (<10ms), not in 20-50ms. I'm just guessing the timings here though but the point is that there's definitely a difference. A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.
- deleted 8y ago
  [deleted]
- yoz-y 8y ago
  Afaik, 10ms is not achievable nowadays, unless you use a very old computer. https://danluu.com/input-lag/ https://danluu.com/input-lag/
  - userbinator 8y ago
    I'd be curious to see the original IBM PC/XT/AT tested too. I guess it would be near the low end of the list too. Also, the last entry in the list provides another reason why Lisp machines never became popular --- 300ms of input lag! That's definitely in unusable territory, especially when other machines of the time were almost an order of magnitude faster.
    - lispm 8y ago
      If you look at the table you'll see that the 3620 from Symbolics in 1986 was an entirely different system. It had a megapixel bitmap-only screen as a separate console (which had mouse, keyboard, serial and an audio interface) with console cables often of 30 meters. The refrigerator size machines often would be running in some machine room and the console would be used in some office room. The console was handled by a separate Front End Processor with a communication protocol over the console cable. An entirely different technology for a different setup. Later Symbolics Lisp machines used different technology for the graphics system, but basically the same console setup. See here for some more info about the 3620: http://lispm.de/3620/3620.html http://lispm.de/3620/3620.html

Const-me 8y ago

I’ve just run “tree /f” from the root of my drive. It printed huge amounts of text but the scrolling remained instant. I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.

mwcampbell 8y ago

Are you using a high-DPI display? In my experience, scrolling in the console is much slower on a high-DPI display.

oldgradstudent 8y ago
Yes, but I use HiDPI displays on Linux and macOS as well.

zadjii 8y ago

I would agree that our perf isn't the best. Almost all of that comes down to our rendering stack - something like 90% of our CPU time is spent rendering the window. This is because at the moment we're stuck with GDI, and IIRC we have to kernel-thunk every row of text we render. It's not a great situation. Stay tuned for updates in this area though. Improving this experience is one of our top priorities.

delfinom 8y ago
GDI?! Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)
- bitcrazed 8y ago
  Hi. Windows Console PM, and @zadjii's whipping boy here :) LOL :) Nice idea - though it turns out that this won't help. Don't ask me why we know this ;) We DO, however, (as @zadjii indicates above) have plans afoot to considerably improve Console's text rendering. Also note that scrolling speed is actually not a good measure of rendering perf! Why? Because at most, scrolling should max-out at around one vertical page every 1/60 of a second. Any more than that and the text tears. This may or may not be an issue for some, but tearing the text upsets people who're visually looking for a particular text layout-pattern which might get discarded if the Console scrolls faster than one page per refresh. This said, yes, we're gonna get faster with less CPU ;)