Hacker News Reader

Comment by foobiekr | Hacker News Reader

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.

View on HN

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

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.

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.

As I recall GNU Emacs does this too, by default. https://www.masteringemacs.org/article/improving-performance...

I expect this is normal practice.

Forget background threads. People don’t know basic programming principles. The thought of debouncing user input didn’t even occur to them.

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).

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.

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.

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...

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?

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.

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.

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.

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.

Behavior solvable.

When a user inserts to backticks, insert the closing backticks immediately.

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.

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.

That solves your problem but probably doesn’t solve the user’s.

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.

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.

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.

All that parsing and rendering can be done in the background, not grinding the UI to a halt. As soon as I strike a key on my keyboard, the letter should appear. Instantly. (Ok, in 20ms or 40ms or whatever)

If I'm actively editing a markdown file, I do not need for it to fire off a re-render on each keystroke. It can wait 500ms before starting to do it, and cancel if I hit another key in the meantime. If I start typing after it has started rendering, then go ahead and finish that cycle while still showing me what I type in real time.

However these events are scheduled, the appearance of my typed characters on the screen is going to always be the priority. There's no reason to block UI while doing this.

I use Thunderbird mail. It often freezes for several seconds while typing text. This is ordinary behavior for modern software. I'm not excusing it, it's just that it's hardly exclusive to Microsoft.

TB is a multithreaded program, but it isn't very good at using it effectively. I've learned through bitter experience to not touch a key or the mouse when it is getting messages.

I've never used Word for DOS. The oldest I've used it "seriously" was word 97 on windows 95 or 98 on a 100 MHz 486. Not book-length documents, but comfortably in the dozens of pages. That thing would fly.

Modern Word lags on a two-page document on an 8 core xeon with 64 GB of RAM. Same PC can run modern games at 4k@60 FPS.

I can agree that maybe modern Word "does more work" than Word 97. But as another commenter said: WTF is that work? And do we even need it?

As a user, all I see is that modern Word's interface has buttons all over the place, taking up half my screen. And when I grab the scroll-bar, it won't scroll until some time after I've released it. Word 97 managed to scroll the contents as I moved the bar just fine.

It also takes forever to start-up on an SSD so fast it can move multiple times the size of that old 486's whole hard drive in one second. WTF is it loading? And once loaded, why is it so slow, since everything can fit in RAM?

> 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.

Markdown parsing can be quite fast. I just benchmarked pulldown-cmark parsing all the Markdown in my blog (10k lines, 1MB) and writing HTML, and it does that in 14ms. Admittedly that's on an M1 Max.

If indeed premature optimization is the root of all evil, then I have lots to atone for.

premature optimization is the root of all evil is the root of all evil.

I think my point was lost on you. Word had code to accommodate the realities of what the application was trying to achieve. This app I mention could trivially be hundreds of times faster just by doing basic things that have been done since before most current SWE were born.

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.

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

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 ....

I imagine the OP means the dos interface.

Reply on news.ycombinator.com