Use rope-like structure instead of line-based array in memory

[dumblob]

I was curious how efficient this editor is and only found out it actually uses lines as the underlying "buffer format".

This works for very small buffers, maybe up to few megabytes on modern machines, but fails quickly for anything bigger.

How about using rope-like structure?

The best I know of are these:

https://github.com/josephg/jumprope-rs https://github.com/cessen/ropey https://github.com/josephg/librope

[larpon]

Interesting. As V's strings and arrays are allocated on the heap I don't quite follow why it's worth using such a much more complex structure internally?

I haven't tested really big files yet since I have plenty of heap memory on my computer - and the editor itself is aimed at small text inputs at this stage (I'm a game dev so I do small, fast and simple things and optimize only when my frame rates tell me I should 🙂)

(I have a TODO that says I'll have to look into maybe using a string builder, but that's about it)

[dumblob]

Interesting. As V's strings and arrays are allocated on the heap I don't quite follow why it's worth using such a much more complex structure internally?

It's really for bigger files. Nothing more, nothing less.

I personally mostly work with smaller files, so even if I need to copy the whole file in memory after each operation, I can live with the tiny lag (tens to hundreds of ms). But for more megabytes it becomes a serious problem - and I edit data files of such sizes (hundreds of MBytes and occasionally even small GBytes). For game dev it's mainly about embedded assets in the source code (tens to small hundreds of MBytes - not more otherwise compilers choke).

But of course YMMV. So feel free to close this as non-issue.

[larpon]

I see, thanks for the links and info