5 ms·

I have a 2000 line markdown file that I edit with the Mac native Markdown+ application. It is so slow that I can type full sentences before it can update. This

I have a 2000 line markdown file that I edit with the Mac native Markdown+ application. It is so slow that I can type full sentences before it can update. This on an M1 with 16GB of RAM doing nothing else. 2000 lines is nothing. I routinely edited book length texts in Microsoft Word for DOS on a 4.77 MHz 8088.

aldonius 4y ago
Not familiar with that specific app, but... I'm guessing it's trying to re-rendering the entire document every keystroke?
- KerrAvon 4y ago
  That’s my guess. Hard to do it any other way for Markdown. However, it could probably do that on a background thread and still be responsive with large amounts of text.
  - ComputerGuru 4y ago
    Forget background threads. People don’t know basic programming principles. The thought of debouncing user input didn’t even occur to them.
    - foobiekr 4y ago
      This. Incredible. Debouncing was done in the early 70s and even someone on;y familiar with more modern similar ideas would note that Nagling was invented in 1984 at the latest...
    - stingraycharles 4y ago
      Not a UI / frontend developer. Doesn’t denouncing user input increase the latency before changes are rendered onto the screen? I would expect the changes to be visible ideally in the next frame, but I guess that’s not really an option?
      - wtallis 4y ago
        Debouncing only has to carry a latency penalty for certain kinds of responses. A good UI should be able to start processing an action as soon as the button goes down, and add/amend the actions later once it's clear whether it was a press and hold, press and release, or double-click. If the appropriate responses to those three options are mutually exclusive to the point that the UI can't respond at all until the user input is fully disambiguated, then the keybindings are probably ill-considered and those unrelated or conflicting functions should not be sharing a button.
      - ComputerGuru 4y ago
        In the strictest sense, yes. But here clearly rendering is taking longer than 1/60s so it wouldn’t matter. The compromise would be to always start rendering immediately rather than wait x ms, but if you detect that the previous rendering hasn’t completed when the next input has arrived then you can start debouncing before rendering until you catch up.
    - rustybolt 4y ago
      What do you mean by 'debouncing' here? I only know it as ignoring keypresses of the same key/button that happen too fast after each other (because they are likely a mechanical or electrical glitch rather than the user actually meaning to press the button/key multiple times). If you mean that, I don't know how it relates to the comment/article since I never needed to do debouncing in a desktop context (only for embedded stuff with actual push button circuitry attached).
      - edflsafoiewq 4y ago
        Same idea, debouncing replaces a sequence of "re-render Markdown" events (button pushes) with a single "re-render" event (button push). Googling "debouncing" will turn up a bunch of articles about it.
      - kiawe_fire 4y ago
        That same concept, but one step removed if you will. The classic example is a data table with a text field that filters/searches the results, pulled from a server. Let’s say you want the results to update “live” as the user types, without having to click a “search” button. So if the user types “bacon” then she sees all results that contain the word “bacon” in them. Problem is, if the act of sending the text field input to the server and waiting for the results is relatively slow and blocks the UI from updating, then each key press causes a delay between the search results updating on the screen, and the next letter showing up in the search field. 1. User types “b” and then the app sends “b” to the server, pauses, gets a response of all results with the letter “b”. 2. User types “a”, and the app sends “ba” to the server… pauses… gets results. She types a “c”, the app sends “bac”, etc. Debouncing, then, means the app waits a short period of time to make sure the user is finished typing before sending the search term. Usually this means every time the user enters a letter into the search field, the app sets a timer for, say, 500ms. If the user doesn’t enter another letter for 500ms, great - send the search term, wait for the results. If the user does enter another letter within 500ms, then she must still be typing, so reset the timer back to 500ms and hold off on sending the search term out to the server.
  - torstenvl 4y ago
    Seems like Markdown could be rendered 1-3 lines at a time, depending on line-height. It isn't like other formats where formatting information is spread all over the place.
    - eyelidlessness 4y ago
      Type two backticks, everything below is fine. Type one more… the entire rest of the syntax tree is potentially a new tree. Backspace, do the whole thing again.
      - worthless-trash 4y ago
        Behavior solvable. When a user inserts to backticks, insert the closing backticks immediately.
        eyelidlessness 4y ago
        That solves your problem but probably doesn’t solve the user’s.
        MauranKilom 4y ago
        Cool, now explain how to do it for backspace. And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block.
        worthless-trash 4y ago
        This may be obvious but if you're trashing the second pair of backticks you obviously want the rest of it to be inside the backticks which required the first re-render so its not a mistake, the user made the request , follow through, render till the next set of bacticks into a block.. no trailing backticks ? Render everything.. thats the choice the user made. > And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block. At no point did I mention that you couldnt wrap code in bacticks, I simply said the default insert would NOT have single pair backticks opening up to a forced re-render of every trailing element.
  - WalterBright 4y ago
    This can be done without multiple threads. MicroEmacs does it by checking the keyboard input buffer every once in a while while rendering. If there's a key in it, it abandons the rendering to go service the key. When there are no keys in the buffer, it tries rendering again. It works so well you never notice this is happening, you just get instance keyboard response.
    - rayiner 4y ago
      As I recall GNU Emacs does this too, by default. https://www.masteringemacs.org/article/improving-performance-emacs-display-engine https://www.masteringemacs.org/article/improving-performance...
      - WalterBright 4y ago
        I expect this is normal practice.
KerrAvon 4y ago
Sure, but in MS Word on an 8088 you were editing in DOS text mode. Markdown+ is parsing and rendering your Markdown in real time. It may be slower than it needs to be, I haven’t used it and don’t know, but it’s doing a lot more work than 1982-era MS Word was. You can still get blazing fast speed for even gigabytes of Markdown if you use instead use something like BBEdit on a current Mac, which would be the equivalent modern user experience.
- abruzzi 4y ago
  I don't know how it did it, but the old DOS version of MS word actually displayed bold/italic/underline in the DOS terminal. It wasn't WYSIWYG but the display was a bit nicer than Wordstar.
  - mickael-kerjean 4y ago
    Ha the DOS terminal, that thing where the fullscreen button wouldn't work and you have to right click -> properties -> layout -> change the window size manually until you have something that work ok. At least, they have fix it in the most recent version of windows ....
    - worthless-trash 4y ago
      I imagine the OP means the dos interface.
  - pmontra 4y ago
    For all the 80s (before the first version for Windows) the terminal was the only thing out there, plus the graphic modes. I think that bold/italic/underline only existed in the graphic mode version (EGA.) https://en.wikipedia.org/wiki/History_of_Microsoft_Word https://en.wikipedia.org/wiki/History_of_Microsoft_Word
- tuatoru 4y ago
  > it’s doing a lot more work than 1982-era MS Word was. That's the point of gp's comment. The software is doing a lot of "work" that it does not need to do, thanks to poor programming. Work is activity that helps to achieve a goal. Whatever Win11's Notepad is doing, it is not that.
RhodesianHunter 4y ago
I'm not sure if it's the case with this particular app, but with many apps these days you have to seek out and download the version specifically for apple silicon. IntelliJ was killing me until I figured this out.
- foobiekr 4y ago
  The problem here isn't the intel/arm issue, it's that the application amplifies handling a single keystroke into what is basically a massive re-rendering job instead of applying any of dozens of well-known solutions to the problem. Applications are simply not well written and most developers are incompetent and unaware of how incompetent they are.

aldonius 4y ago

Not familiar with that specific app, but... I'm guessing it's trying to re-rendering the entire document every keystroke?

KerrAvon 4y ago
That’s my guess. Hard to do it any other way for Markdown. However, it could probably do that on a background thread and still be responsive with large amounts of text.
- ComputerGuru 4y ago
  Forget background threads. People don’t know basic programming principles. The thought of debouncing user input didn’t even occur to them.
  - foobiekr 4y ago
    This. Incredible. Debouncing was done in the early 70s and even someone on;y familiar with more modern similar ideas would note that Nagling was invented in 1984 at the latest...
  - stingraycharles 4y ago
    Not a UI / frontend developer. Doesn’t denouncing user input increase the latency before changes are rendered onto the screen? I would expect the changes to be visible ideally in the next frame, but I guess that’s not really an option?
    - wtallis 4y ago
      Debouncing only has to carry a latency penalty for certain kinds of responses. A good UI should be able to start processing an action as soon as the button goes down, and add/amend the actions later once it's clear whether it was a press and hold, press and release, or double-click. If the appropriate responses to those three options are mutually exclusive to the point that the UI can't respond at all until the user input is fully disambiguated, then the keybindings are probably ill-considered and those unrelated or conflicting functions should not be sharing a button.
    - ComputerGuru 4y ago
      In the strictest sense, yes. But here clearly rendering is taking longer than 1/60s so it wouldn’t matter. The compromise would be to always start rendering immediately rather than wait x ms, but if you detect that the previous rendering hasn’t completed when the next input has arrived then you can start debouncing before rendering until you catch up.
  - rustybolt 4y ago
    What do you mean by 'debouncing' here? I only know it as ignoring keypresses of the same key/button that happen too fast after each other (because they are likely a mechanical or electrical glitch rather than the user actually meaning to press the button/key multiple times). If you mean that, I don't know how it relates to the comment/article since I never needed to do debouncing in a desktop context (only for embedded stuff with actual push button circuitry attached).
    - edflsafoiewq 4y ago
      Same idea, debouncing replaces a sequence of "re-render Markdown" events (button pushes) with a single "re-render" event (button push). Googling "debouncing" will turn up a bunch of articles about it.
    - kiawe_fire 4y ago
      That same concept, but one step removed if you will. The classic example is a data table with a text field that filters/searches the results, pulled from a server. Let’s say you want the results to update “live” as the user types, without having to click a “search” button. So if the user types “bacon” then she sees all results that contain the word “bacon” in them. Problem is, if the act of sending the text field input to the server and waiting for the results is relatively slow and blocks the UI from updating, then each key press causes a delay between the search results updating on the screen, and the next letter showing up in the search field. 1. User types “b” and then the app sends “b” to the server, pauses, gets a response of all results with the letter “b”. 2. User types “a”, and the app sends “ba” to the server… pauses… gets results. She types a “c”, the app sends “bac”, etc. Debouncing, then, means the app waits a short period of time to make sure the user is finished typing before sending the search term. Usually this means every time the user enters a letter into the search field, the app sets a timer for, say, 500ms. If the user doesn’t enter another letter for 500ms, great - send the search term, wait for the results. If the user does enter another letter within 500ms, then she must still be typing, so reset the timer back to 500ms and hold off on sending the search term out to the server.
- torstenvl 4y ago
  Seems like Markdown could be rendered 1-3 lines at a time, depending on line-height. It isn't like other formats where formatting information is spread all over the place.
  - eyelidlessness 4y ago
    Type two backticks, everything below is fine. Type one more… the entire rest of the syntax tree is potentially a new tree. Backspace, do the whole thing again.
    - worthless-trash 4y ago
      Behavior solvable. When a user inserts to backticks, insert the closing backticks immediately.
      - eyelidlessness 4y ago
        That solves your problem but probably doesn’t solve the user’s.
      - MauranKilom 4y ago
        Cool, now explain how to do it for backspace. And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block.
        worthless-trash 4y ago
        This may be obvious but if you're trashing the second pair of backticks you obviously want the rest of it to be inside the backticks which required the first re-render so its not a mistake, the user made the request , follow through, render till the next set of bacticks into a block.. no trailing backticks ? Render everything.. thats the choice the user made. > And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block. At no point did I mention that you couldnt wrap code in bacticks, I simply said the default insert would NOT have single pair backticks opening up to a forced re-render of every trailing element.
- WalterBright 4y ago
  This can be done without multiple threads. MicroEmacs does it by checking the keyboard input buffer every once in a while while rendering. If there's a key in it, it abandons the rendering to go service the key. When there are no keys in the buffer, it tries rendering again. It works so well you never notice this is happening, you just get instance keyboard response.
  - rayiner 4y ago
    As I recall GNU Emacs does this too, by default. https://www.masteringemacs.org/article/improving-performance-emacs-display-engine https://www.masteringemacs.org/article/improving-performance...
    - WalterBright 4y ago
      I expect this is normal practice.

KerrAvon 4y ago

Sure, but in MS Word on an 8088 you were editing in DOS text mode. Markdown+ is parsing and rendering your Markdown in real time. It may be slower than it needs to be, I haven’t used it and don’t know, but it’s doing a lot more work than 1982-era MS Word was. You can still get blazing fast speed for even gigabytes of Markdown if you use instead use something like BBEdit on a current Mac, which would be the equivalent modern user experience.

abruzzi 4y ago
I don't know how it did it, but the old DOS version of MS word actually displayed bold/italic/underline in the DOS terminal. It wasn't WYSIWYG but the display was a bit nicer than Wordstar.
- mickael-kerjean 4y ago
  Ha the DOS terminal, that thing where the fullscreen button wouldn't work and you have to right click -> properties -> layout -> change the window size manually until you have something that work ok. At least, they have fix it in the most recent version of windows ....
  - worthless-trash 4y ago
    I imagine the OP means the dos interface.
- pmontra 4y ago
  For all the 80s (before the first version for Windows) the terminal was the only thing out there, plus the graphic modes. I think that bold/italic/underline only existed in the graphic mode version (EGA.) https://en.wikipedia.org/wiki/History_of_Microsoft_Word https://en.wikipedia.org/wiki/History_of_Microsoft_Word
tuatoru 4y ago
> it’s doing a lot more work than 1982-era MS Word was. That's the point of gp's comment. The software is doing a lot of "work" that it does not need to do, thanks to poor programming. Work is activity that helps to achieve a goal. Whatever Win11's Notepad is doing, it is not that.

RhodesianHunter 4y ago

I'm not sure if it's the case with this particular app, but with many apps these days you have to seek out and download the version specifically for apple silicon. IntelliJ was killing me until I figured this out.

foobiekr 4y ago
The problem here isn't the intel/arm issue, it's that the application amplifies handling a single keystroke into what is basically a massive re-rendering job instead of applying any of dozens of well-known solutions to the problem. Applications are simply not well written and most developers are incompetent and unaware of how incompetent they are.