From: matz@... (Yukihiro Matsumoto)
Date: 2003-06-30T18:45:51+09:00
Subject: Re: Memory behavior of String#dup

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. 

|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?

							matz.