3 ms·
> A memcpy/memove() runs at many GB/s on a typical machine today, so you would have to be editing absolutely huge files to notice. That's only good if your tex
by TuringTest 9y ago
> A memcpy/memove() runs at many GB/s on a typical machine today, so you would have to be editing absolutely huge files to notice.
That's only good if your text happen to be raw text; I guess it won't work so well if it's rich text with needs to be converted to lightweight objects before being processed, where you'll want every object to be memory-aligned. And I wonder how well that approach works if your virtual memory space is paginated, which wasn't common in the 90's, but is practically everywhere nowadays.
- eludwig 9y agoI wrote a wysiwyg, memory-based rich text editor from scratch on the Mac back in the 90s called Scorpio. It had support for fonts, colors, styles, inline pictures, etc. It used a single buffer for text and I had no problem with insert/delete into this buffer even back then, even with ginormous amounts of text. The "trick" (not really a trick, but..) was to use external data structures for the style runs that had offsets into the text array for styles/rich object support. That way I didn't need to worry about object alignment or whatever. The downside of that approach was that there was bookkeeping to do in these external structures when text was inserted/deleted (indexes would need to be increased/decreased by a fixed amount, etc). The other major downside was that multi-level undo became problematic. It was easy enough to do one level of undo, which I did. BTW, writing a word processor/text editor from scratch is a blast. I highly recommend it!