From: jean.boussier@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:92589] [Ruby trunk Feature#15836] [Proposal] Make Module#name and Symbol#to_s return their internal fstrings
Date: Tue, 07 May 2019 15:46:10 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-77950.20190507154610.6e38deaa4848b4d7@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15836.20190507143338@ruby-lang.org
Issue #15836 has been updated by byroot (Jean Boussier).
@mame very good point. I'll try to run our app against that patch tomorrow.
----------------------------------------
Feature #15836: [Proposal] Make Module#name and Symbol#to_s return their internal fstrings
https://bugs.ruby-lang.org/issues/15836#change-77950
* Author: byroot (Jean Boussier)
* Status: Feedback
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
# Why ?
In many codebases, especially Rails apps, these two methods are the source of quite a lot of object allocations.
`Module#name` is often accessed for various introspection features, autoloading etc.
`Symbol#to_s` is access a lot by HashWithIndifferentAccess other various APIs accepting both symbols and strings.
Returning fstrings for both of these methods could significantly reduce allocations, as well as sligthly reduce retention as it would reduce some duplications.
Also, more and more Ruby APIs are now returning fstrings. `frozen_string_literal`AFAIK should become the default some day, string used as hash keys are now automatically interned as well.
### Backward compatibilty
Of course this is not fully backward compatible, it's inevitable that some code in the wild is mutating the strings returned by these methods, but I do believe it's a rare occurence, and easy to fix.
### Implementation
I implemented it here: https://github.com/ruby/ruby/pull/2175
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2019-05-07 15:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-15836.20190507143338@ruby-lang.org>
2019-05-07 14:33 ` [ruby-core:92585] [Ruby trunk Feature#15836] [Proposal] Make Module#name and Symbol#to_s return their internal fstrings jean.boussier
2019-05-07 14:42 ` [ruby-core:92586] " mame
2019-05-07 14:54 ` [ruby-core:92587] " hanmac
2019-05-07 15:36 ` [ruby-core:92588] " chris
2019-05-07 15:46 ` jean.boussier [this message]
2019-05-07 16:47 ` [ruby-core:92590] " shevegen
2019-05-07 23:05 ` [ruby-core:92592] " jean.boussier
2019-05-08 3:15 ` [ruby-core:92593] " ruby-core
2019-05-08 8:28 ` [ruby-core:92595] " jean.boussier
2019-05-08 11:30 ` [ruby-core:92597] " jean.boussier
2019-05-08 14:21 ` [ruby-core:92598] " pdahorek
2019-06-13 6:05 ` [ruby-core:93090] " duerst
2019-06-13 6:12 ` [ruby-core:93091] " matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-77950.20190507154610.6e38deaa4848b4d7@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).