Steve [RubyTalk] wrote:
> Robert Klemme wrote:
>>> I might be wrong
>>>
>> You're not.
>>
>>> - but I'm pretty sure that substrings in ruby are
>>> created with copy-on-write. That is, when you take a substring, a
>>> new block of memory isn't allocated to the new String, it
>>> references the same block of memory as the original string - the
>>> allocation of a new block of memory only occurs when one of the
>>> strings is modified.
>>>
>> Exactly.  It seems this would be the simplest solution.
>>
>>
> That sounds like absolutely great news - a _very_ pleasant surprise. I
> couldn't have hoped for anything better. (Thanks!)
>
> I assume that if I do something like:
>
>     # Assume offsets is a pre-computed array of positive integer
> positions into the String originalstr.

Care to unveil a bit of the nature of the computation that yields those
indexes?

>     # with offsets[0]==0 and offsets[-1]==@originalstr.size
>     @fields=Array.new (offsets.size-1)
>     for i in 1..(offsets.size) do
>       # I assume this next line is what is meant by a Ruby sub-string?
>       @fields[i-1]=@originalstr[offsets[i-1]..offsets[i]]
>     end
>
> .. and, assuming that @fields is exposed only as a read-only
> attribute, that I can assume the memory it consumes to be independent
> of the length of originalstr and dependent only upon numfields?

You can help keeping this read only be freezing all strings involved.

> While I've no reason to doubt this confirmed answer, by any chance can
> someone suggest a good way to demonstrate that this is the case
> without resorting to either using very large strings and looking at
> VM usage of the interpreter process... or resorting to reviewing the
> source to Ruby's implementation?

The only additional method of verification that comes to mind is to ask
Matz. :-)

Kind regards

    robert