4 ms·
> This will speed things up and reduce fragmentation Does this really make much of a practical difference these last decades? I wrote a text editor back in the
by badsectoracula 2y ago
> This will speed things up and reduce fragmentation
Does this really make much of a practical difference these last decades? I wrote a text editor back in the late 90s in DOS using DJGPP with per-line allocation and it worked fine on the Pentium MMX i had at the time (and my approach to optimization at that time was be ignorant of the concept :-P), i'm not sure it'd really make much of a difference on any desktop or laptop CPU released past 2000 - at least as far as users editing text files are concerned (might make a difference if you try to open a multiGB file with barely a line break and accidentally press a letter :-P).
- HexDecOctBin 2y agoNo, it won't. You might want an arena for other reasons (better reasoning about lifetimes, preventing nest of pointers, etc.), but an array of line array approach to text editors is totally valid (except in the case of millions of extremely small lines).
- lanstin 2y agoI do from time to time open files of millions of small lines. To this day vim handles it better than emacs. These would be log files.
- HexDecOctBin 2y agoLog files have lines that are long enough, I was thinking more of one/two-character long lines (such that the overhead of malloc bookkeeping would be more than the line size in memory). Regardless, Emacs also stores the data in a single array with a gap in middle (and memcpy is relatively cheap), so what slows it down is probably not the choice of data structure but everything else built around it.
- lanstin 2y agoYeah I have very high limits for paren matching and syntax highlighting so probably those scanners.