Skip to content

Detect in-place modifications on Strings #15788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 27, 2014

Conversation

sgrif
Copy link
Contributor

@sgrif sgrif commented Jun 18, 2014

No description provided.

@@ -41,6 +41,7 @@ def reload(*)
def initialize_dup(other) # :nodoc:
super
calculate_changes_from_defaults
@original_raw_attributes = original_raw_attributes.dup
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to understand, why we are needing to dup this now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out we don't. There was a different issue causing this.

@rafaelfranca
Copy link
Member

@sgrif does the object allocation grew substantially with this change? For what I saw we are allocating a new string for each string attribute every time we are going to write the model instance right?

@sgrif
Copy link
Contributor Author

sgrif commented Jun 27, 2014

Correct, this will increase string allocations, however in context of the
rest of the work done, the performance penalty is extremely small.
On Jun 27, 2014 12:09 PM, "Rafael Mendonça França" notifications@github.com
wrote:

@sgrif https://github.com/sgrif does the object allocation grew
substantially with this change? For what I saw we are allocating a new
string for each string attribute every time we are going to write the model
instance right?


Reply to this email directly or view it on GitHub
#15788 (comment).

@rafaelfranca rafaelfranca merged commit c7802dc into rails:master Jun 27, 2014
rafaelfranca added a commit that referenced this pull request Jun 27, 2014
Detect in-place modifications on Strings
sgrif added a commit that referenced this pull request Oct 15, 2015
This type adds an escape hatch to apps for which string duping causes
unacceptable memory growth. The reason we are duping them is in order to
detect mutation, which was a feature added to 4.2 in #15674. The string
type was modified to support this behavior in #15788.

Memory growth is really only a concern for string types, as it's the
only mutable type where the act of coersion does not create a new object
regardless (as we're usually returning an object of a different class).

I do feel strongly that if we are going to support detecting mutation,
we should do it universally for any type which is mutable. While it is
less common and ideomatic to mutate strings than arrays or hashes, there
shouldn't be rules or gotchas to understanding our behavior.

However, I also appreciate that for apps which are using a lot of string
columns, this would increase the number of allocations by a large
factor. To ensure that we keep our contract, if you'd like to opt out of
mutation detection on strings, you'll also be option out of mutation of
those strings.

I'm not completely married to the thought that strings coming out of
this actually need to be frozen -- and I think the name is correct
either way, as the purpose of this is to provide a string type which
does not detect mutation.

In the new implementation, I'm only overriding `cast_value`. I did not
port over the duping in `serialize`. I cannot think of a reason we'd
need to dup the string there, and the tests pass without it.
Unfortunately that line was introduced at a time where I was not nearly
as good about writing my commit messages, so I have no context as to
why I added it. Thanks past Sean. You are a jerk.
@sgrif sgrif deleted the sg-mutable-strings branch March 14, 2018 20:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants