[ruby-core:95713] [Ruby master Feature#16150] Add a way to request a frozen string from to_s
From:
duerst@...
Date:
2019-11-06 00:29:03 UTC
List:
ruby-core #95713
Issue #16150 has been updated by duerst (Martin D=FCrst). Just to cross-check: Eregon (Benoit Daloze) wrote: > I find it frustrating that the change is reverted without much else than = "a possible incompatibility reported by one user" I didn't find the text "a possible incompatibility reported by one user" an= ywhere in this issue. Hiroshi (Shibata) writes "I got the issue report from= Heroku users.", which indicates it's more than a single user. > and for which we already have a plan to address it easily (just use the l= atest Rails of that release series, which is likely already needed for othe= r fixes). I think it's not a bad idea to have a bit of slack for version combinations= . If we put too many restrictions on what version of something can be combi= ned with what version of something else, we easily get into situations wher= e there are no viable combinations anymore. ---------------------------------------- Feature #16150: Add a way to request a frozen string from to_s https://bugs.ruby-lang.org/issues/16150#change-82499 * Author: headius (Charles Nutter) * Status: Open * Priority: Normal * Assignee: Eregon (Benoit Daloze) * Target version: = ---------------------------------------- Much of the time when a user calls to_s, they are just looking for a simple= string representation to display or to interpolate into another string. In= my brief exploration, the result of to_s is rarely mutated directly. It seems that we could save a lot of objects by providing a way to explicit= ly request a *frozen* string. For purposes of discussion I will call this to_frozen_string, which is a te= rrible name. This would reduce string allocations dramatically when applied to many comm= on to_s calls: * Symbol#to_frozen_string could always return the same cached String repres= entation. This method is *heavily* used by almost all Ruby code that interm= ingles Symbols and Strings. * nil, true, false, and any other singleton values in the system could simi= larly cache and return the same String object. * The strings coming from core types could also be in the fstring cache and= deduplicated as a result. * User-provided to_s implementations could opt-in to caching and returning = the same frozen String object when the author knows that the result will al= ways be the same. A few ideas for what to call this: * `to_fstring` or `fstring` reflects internal the "fstring" cache but is pe= rhaps not obvious for most users. * `to_s(frozen: true)` is clean but there will be many cases when the kwarg= s hash doesn't get eliminated, making matters worse. * `def to_s(frozen =3D false)` would be mostly free but may not be compatib= le with existing to_s params (like `Integer#to_s(radix)` This idea was inspired by @schneems's talk at RubyConf Thailand, where he s= howed significant overhead in ActiveRecord from Symbol#to_s allocation. -- = https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=3Dunsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>