3 ms·
> Editing implementation for single lines of text do not work well at all for entire text files. Operations become incredibly slow, which is why we invented thi
by geocar 5y ago
> Editing implementation for single lines of text do not work well at all for entire text files. Operations become incredibly slow, which is why we invented things like rope data structures and buffered views.
memmove() is about 100 gigabytes a second on my computer. That's 100 megabytes every single msec. My screen refreshes at about 100hz. None of my source code files are even 1 megabyte let alone 100 megabytes, so at least on my computer, for all of the files I edit, there isn't a single operation that a "rope" or a "buffered view" could offer over the naive because I could literally just rewrite the entire file in C 100 times every keystroke, and I think for many operations it is obvious how to do better.
For this reason and others I think it's absolutely plausible for a beginner to self-teach themselves how to write a good text editor and even improve on things, and I would never want to discourage someone from a discovery they have both the interest and the time for.
- tl 5y ago> None of my source code files are even 1 megabyte let alone 100 megabytes Source code, sure. Log files and other kinds of text can routinely can be quite large. Also, within the context of source code, colorization and other useful features can be far less expensive if you only have to reapply them to limited section of the current file.
- hlbjhblbljib 5y agobad editors hang on large files. Others hang on large files without a newline in the first 100MB. You don't just need to memmove, you need to put that data into a structure that can be edited.
- dataflow 5y ago> memmove() is about 100 gigabytes a second on my computer Does DRAM even support speeds that high? I thought DDR4 goes to like 25 GB/s. Are you measuring cache speed?