Issue #16047 has been updated by jeremyevans0 (Jeremy Evans).


byroot (Jean Boussier) wrote:
> The speedup mostly come from reduced GC pressure. Consider the following snippet:
> 
> ```ruby
> def call(env)
>   env["HTTP_PATH_INFO"]
> end
> ```
> 
> Without `frozen_string_literal: true` it's pretty much equivalent to:
> 
> ```ruby
> HTTP_PATH_INFO = "HTTP_PATH_INFO".freeze
> def call(env)
>   env[HTTP_PATH_INFO.dup]
> end
> ```

Unfortunately, this is not a good example, because even without `frozen_string_literal: true`, Ruby already optimizes this case.  Try the following:

```
GC.disable
ObjectSpace.count_objects[:T_STRING]
x = ObjectSpace.count_objects[:T_STRING]
h = {'a'=>1}
100000.times{h['a']}
p(ObjectSpace.count_objects[:T_STRING] - x)
```

> > we could have the best of both worlds if dynamic string literals were not frozen by the magic comment
> 
> I don't really see it as a upside. IMO these are literals before being "dynamic", and as such it seems much more consistent to me that they'd be frozen as well.

I agree it makes more consistent to freeze both static and dynamic strings literals.  Personally, I think only freezing static strings is more useful behavior, even if less consistent, but that ship has sailed and it would be worse to try to change the behavior now.

----------------------------------------
Misc #16047: Reconsider impact of frozen_string_literal on dynamic strings
https://bugs.ruby-lang.org/issues/16047#change-80413

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
The rationale for introducing `frozen_string_literal` was because rubyists were starting to litter their code with `"".freeze` for optimization, and it's ugly.

But by using frozen_string_literal we introduce the opposite problem: we must litter the code with `"".dup` in order to have mutable strings, and it's ugly.

The rationale for freezing all strings including dynamic was because it's [easy to explain]
(https://docs.google.com/document/u/1/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub)
This may be true, but at the expense of making it cumbersome to use. And freezing dynamic strings is useless (no-op) for memory optimization, but making it mutable again via `"foo #{bar}".dup` means we allocate two strings where only one was needed before.

In my personal experience using frozen_string_literal, I find that static strings are usually ok to freeze without changing anything else, but that freezing dynamic strings often create bugs that require `+""` or `"".dup` boilerplate to circumvent. So in the end I found myself stopping regular use of that feature, since it's more trouble than it's worth.

As such I'd like to ask other rubyists how has been their experience with **actually using** frozen_string_literal on a day-to-day basis; if my experience is unique or common. Thank you for sharing your thoughts.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>