From: Robert Klemme <bob.news@...>
Date: 2003-06-30T19:17:14+09:00
Subject: Re: Memory behavior of String#dup


"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag
news:1056966350.233426.26926.nullmailer@picachu.netlab.jp...
> Hi,
>
> In message "Re: Memory behavior of String#dup"
>     on 03/06/30, "Robert Klemme" <bob.news@gmx.net> writes:
>
> |> When memory is already shared between strings, it does copy-on-write,
> |> otherwise it copies.  From my observation, many of duped strings are
> |> modified right after the dup, so that I felt it is wise to avoid
> |> making new internal copy-on-write entries for duping.
> |
> |s1 = "foo"
> |s2 = s2.dup
> |
> |So, if I understand you correctly s1 and s2 don't share the same byte
> |sequence since s1 is the only string referring tho the sequence "foo"
when
> |the dup occurs (i.e. the sequence is not shared).  Is that correct?
>
> In this case, fortunately memory is shared.  Since all literal strings
> have their copy-on-write entries internally.

Ok, then I possibly didn't understand you correctly.

> |The question why I'm asking is, that for hashes where an entry shares
the
> |key (either directly because it is the same string in h[s1]=s1 or
> |indirectly because the value is an instance that refers the key
> |indirectly) there would be enourmous memory consumption if all those
> |dup'ed hash key strings did also contain a copy of the byte sequence.
The
> |problem I have with this duping is that I can't prevent it.  So there's
at
> |least the overhead of a new created String instance, because apparently
(v
> |1.7.3) the Hash doesn't honor the freeze state of the string.
>
> String hash keys are duped and frozen with their memory _shared_.  Is
> this what you want to hear?

:-))  Yeah, that sounds good.

Though I still worry about the overhead of one more ruby instance (there
must be some bookkeeping done etc.).  Is this neglectible?

    robert