4 ms·

I would recommend using the ropey crate for easy performance gains. A string buffer is quick to implement but you will hit a wall as soon as you need to edit la

I would recommend using the ropey crate for easy performance gains. A string buffer is quick to implement but you will hit a wall as soon as you need to edit large files.

mizmar 7mo ago
It's not that bad. You need really large files to notice. The largest realistic file I'll ever touch - sqlite3 amalgamation with 270k lines and 9.1 kB - still takes only 6 ms to memmove it on my poor laptop. Any regular up-to 10k lines file is memmoved in order of microseconds.
- sampullman 7mo ago
  That's true for code editing, but it's nice to not have to reach for a different solution when editing huge files. Sometimes I like to open up big log files, JSON test data, etc.
  - oneeyedpigeon 7mo ago
    Do you actually edit big log files?
    - spongebobstoes 7mo ago
      I interactively pare down log files to just the parts I need. I rarely save the result
  - mejutoco 7mo ago
    I am always surprised even vim chokes on files with one massive line. That could be a useful optimization too.
- zesterer 7mo ago
  Yes, absolutely. I've since switched to rope-backed buffers, but I don't think the rope itself is actually adding much from a performance standpoint, even for really very large files. We talk about big-O complexity a lot when talking about things like this, but modern machines are scarily good at copying around enormous linear buffers of data. Shifting even hundreds of megabytes of text might not even be visible in your benchmark profiling, if done right. When benchmarking, I discovered that the `to_pos`/`to_coord` functions, which translate between buffer byte positions and screen coordinates, were by far the heaviest operation. I could have solved that problem entirely simply by maintaining a list of line offsets and binary-searching through it.
zesterer 7mo ago
Unmentioned in the post, but I have since switched to a third-party rope library (crop, not ropey). At some point I'd like to implement one myself, but for now this does the job.

I would recommend using the ropey crate for easy performance gains. A string buffer is quick to implement but you will hit a wall as soon as you need to edit large files.

mizmar 7mo ago

It's not that bad. You need really large files to notice. The largest realistic file I'll ever touch - sqlite3 amalgamation with 270k lines and 9.1 kB - still takes only 6 ms to memmove it on my poor laptop. Any regular up-to 10k lines file is memmoved in order of microseconds.

sampullman 7mo ago
That's true for code editing, but it's nice to not have to reach for a different solution when editing huge files. Sometimes I like to open up big log files, JSON test data, etc.
- oneeyedpigeon 7mo ago
  Do you actually edit big log files?
  - spongebobstoes 7mo ago
    I interactively pare down log files to just the parts I need. I rarely save the result
- mejutoco 7mo ago
  I am always surprised even vim chokes on files with one massive line. That could be a useful optimization too.
zesterer 7mo ago
Yes, absolutely. I've since switched to rope-backed buffers, but I don't think the rope itself is actually adding much from a performance standpoint, even for really very large files. We talk about big-O complexity a lot when talking about things like this, but modern machines are scarily good at copying around enormous linear buffers of data. Shifting even hundreds of megabytes of text might not even be visible in your benchmark profiling, if done right. When benchmarking, I discovered that the `to_pos`/`to_coord` functions, which translate between buffer byte positions and screen coordinates, were by far the heaviest operation. I could have solved that problem entirely simply by maintaining a list of line offsets and binary-searching through it.

zesterer 7mo ago

Unmentioned in the post, but I have since switched to a third-party rope library (crop, not ropey). At some point I'd like to implement one myself, but for now this does the job.