3 ms·

Even a Z80 would struggle to keep up: you're looking at something like 17-18 T-states/byte for a useful memcpy, which is ~215 KBytes/sec at 4 MHz. Suppose your

by tom_ 7y ago

Even a Z80 would struggle to keep up: you're looking at something like 17-18 T-states/byte for a useful memcpy, which is ~215 KBytes/sec at 4 MHz. Suppose your document is 32 KBytes, and you're inserting chars at the start. It's going to take 0.2 seconds per keypress! You'd notice. (0.2 seconds per keypress = 300 keypresses per second. Assume 6 keypresses per word (5 letters and a space), and that's 50 wpm. You probably type faster than that.)

kragen 7y ago
Thanks! I don't know much about 8080-family performance, but I remember sometimes WordStar would fall behind reasonably fast typing on a 4MHz Z80, even 50 or 60 wpm. But it was doing word wrap, too. I think you mean 300 keypresses per minute.
- deleted 7y ago
  [deleted]
Someone 7y ago
”Suppose your document is 32 KBytes, and you're inserting chars at the start.” Who has such enormous documents, and who inserts chars at the start :-) ? Given the 64kB limit for (program+data), you’ll soon need some way to keep things on disk (most likely by having a master document that lists the names of the files storing each ‘chapter’ in the complete document, and requiring the user to manually switch from file to file) Therefore, I would implement that, search/replace and a yank buffer before I started worrying about such relatively edgy performance issues. For comparison, the original MacWrite on a 128k Macintosh handled only 2 to 3 pages of text, and also soon got slower than that 0.2s per key press. It was smart enough to skip updates if typing was relatively fast, though. that is a feature you might want to add (e.g. by peeking into the keyboard buffer before refreshing the screen), as the best way to speed up code is by doing less.
- kragen 7y ago
  These are good points, but a thing to keep in mind is that we were discussing how to update the internal buffer data structure, not refreshing the screen. However, you could imagine peeking into the keyboard buffer so as to do a batch-insert if several keystrokes happened while you were doing the memmove(), so that the next memmove() would insert two or three bytes instead of just one — then at least it wouldn't progressively fall further behind your keystrokes. All else being equal, though, I think a source-code editor that can comfortably handle a 48-kibibyte source file is considerably superior to one that can only handle, say, 10 or 20 kilobytes before it starts getting sluggish. Searching works better, refactoring is easier, you need less header files in C, and you can split and join source files a lot less often. Note that qe.c itself is (barely) over 20 kilobytes, and that's using TAB characters for compression.

by tom_ 7y ago

kragen 7y ago

Thanks! I don't know much about 8080-family performance, but I remember sometimes WordStar would fall behind reasonably fast typing on a 4MHz Z80, even 50 or 60 wpm. But it was doing word wrap, too. I think you mean 300 keypresses per minute.

deleted 7y ago
[deleted]

Someone 7y ago

”Suppose your document is 32 KBytes, and you're inserting chars at the start.” Who has such enormous documents, and who inserts chars at the start :-) ? Given the 64kB limit for (program+data), you’ll soon need some way to keep things on disk (most likely by having a master document that lists the names of the files storing each ‘chapter’ in the complete document, and requiring the user to manually switch from file to file) Therefore, I would implement that, search/replace and a yank buffer before I started worrying about such relatively edgy performance issues. For comparison, the original MacWrite on a 128k Macintosh handled only 2 to 3 pages of text, and also soon got slower than that 0.2s per key press. It was smart enough to skip updates if typing was relatively fast, though. that is a feature you might want to add (e.g. by peeking into the keyboard buffer before refreshing the screen), as the best way to speed up code is by doing less.

kragen 7y ago
These are good points, but a thing to keep in mind is that we were discussing how to update the internal buffer data structure, not refreshing the screen. However, you could imagine peeking into the keyboard buffer so as to do a batch-insert if several keystrokes happened while you were doing the memmove(), so that the next memmove() would insert two or three bytes instead of just one — then at least it wouldn't progressively fall further behind your keystrokes. All else being equal, though, I think a source-code editor that can comfortably handle a 48-kibibyte source file is considerably superior to one that can only handle, say, 10 or 20 kilobytes before it starts getting sluggish. Searching works better, refactoring is easier, you need less header files in C, and you can split and join source files a lot less often. Note that qe.c itself is (barely) over 20 kilobytes, and that's using TAB characters for compression.