4 ms·

What's the catch? Why hasn't this become the standard way to represent text?

• jeffbee 6y ago
  Representing a short string as a contiguous vector of characters takes much less CPU time. The rope doesn't really hit its stride until you want to do something that a vector is bad at, such as splicing something into the middle of a long string.
• ehnto 6y ago
  I did like the quote "While strings are occasionally the right choice..." Nearly three decades of utility since, quite the occasion! Certainly, we could all have been wrong this entire time. So often in programming I find that my working, perfectly useful software, unbeknownst to me, was wrong all along! Imagine my face on the day! (I am being facetious, it is of course perfectly valid to challenge the status quo)
• raphlinus 6y ago
  It depends hugely on the workload. Ropes are ideal for editing sessions, where you have a sequence of small edits on a large string. But if the string is small, just storing it contiguously is simpler and faster. They're also good for forming larger strings by concatenating smaller ones. But if you can structure your code so that it just appends to a buffer, for example, by threading a mutable string buffer reference through function calls rather than returning strings, that's also faster. So, as with most such tradeoffs, it depends on what you're trying to do.
• vbezhenar 6y ago
  CPUs are very fast at copying memory. And continuous memory allows for efficient use of CPU caches. So for small string sizes simple algorithms are better. Another reason might be compacting GC. When you compact the heap, you need to rewrite pointers. So you need less objects overall and less pointers. When your string is just one array, it's much more friendly than having bunch of substrings with pointers. If you're dealing with megabyte strings, you need to think about algorithms, ropes might be the right choice.