Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The worst way to store and manipulate text is to use an array. Firstly, the entire file must be loaded into the array first, which raises issues with time and memory. Even worse still, every insertion and deletion requires each element in the array to be moved. There are more downsides, but already this method is clearly not practical. The array can be dismissed as an option rather quickly.

Someone has clearly not heard of Notepad nor used the prolific quantity of text editors for DOS that appeared in the 80s/early 90s, a time when memory bandwidths were in the low MB/s; or even before that, micros with CP/M where memory bandwidths were measured in KB/s (and the whole address space was only 64k). Modern systems have memory bandwidths of dozens of GB/s.

Or perhaps that old saying really applies: worse is better.

IMHO an array is all you need for a regular general-purpose text editor. I hate needless complexity in software, but unfortunately others seem to love it.



> an array is all you need for a regular general-purpose text editor.

until you try to open up a multi gigabyte log file in notepad, and find that it's consuming all your system resources.

But opening that same file in sublime text works perfectly, scrolls fast and zero lag. Guess which one is my daily driver?


Reading log files is completely different than constantly manipulating source code? I wish editors have read-only mode that uses data structure that lazily loaded continuous memory.


if you use an array in the naïve way on an 8080 with, as you correctly point out, memory bandwidths on the order of 16 kilobytes per second, as soon as your text file has grown to 48 kilobytes (about 17 printed pages and less than half a floppy disk), inserting a letter near the beginning of it will take multiple seconds; you can type several times as fast as the editor can respond, even with hunt and peck

consequently the editors we used on those computers did not use this approach

however, a gap buffer is perfectly workable, and preserves most of the array's advantages, such as rapid text search. and so emacs continues to use gap buffers to this day


Yep.

Q: How big is the 90th percentile text file?

64KB? That text file fits in some some level of cache and not RAM. An array is just fine most of the time.

Use a different purpose-built editor for those multi-GB text files.


If you _have _ an editor purpose-built for those files, why not just use it for everything?


Because those editors aren't your preferred editor? I don't really care about being able to edit files that big so that's not going to be the reason why I pick an editor.


A craftsmen has different tools for different purposes.

E.g. Text editor Hex editor Source code editor


Turns out there's no need for that when all the good editors support all of those things out the box.


Agreed. Our computers are so powerful, do we really need this additional complexity?

And of course, if performance becomes an issue, we can make minor improvements then.


That’s why all these programs land these improvements - the performance optimizations were needed. It gets tricky of course because a performance optimization you needed at one time may no longer be needed as HW perf increased or may even be a penalty as HW architecture diverged from the target one that was optimized for.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: