Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Use `Symbol` more #60630
Merged
Use `Symbol` more #60630
Conversation
|
@bors try |
bors
added a commit
that referenced
this pull request
May 8, 2019
Use `Symbol` more A `Symbol` can be equated with a string (e.g. `&str`). This involves a TLS lookup to get the chars (and a Mutex lock in a parallel compiler) and then a char-by-char comparison. This functionality is convenient but avoids one of the main benefits of `Symbol`s, which is fast equality comparisons. This PR removes the `Symbol`/string equality operations, forcing a lot of existing string occurrences to become `Symbol`s. Fortunately, these are almost all static strings (many are attribute names) and we can add static `Symbol`s as necessary, and very little extra interning occurs. The benefits are (a) a slight speedup (possibly greater in a parallel compiler), and (b) the code is a lot more principled about `Symbol` use. The main downside is verbosity, particularly with more `use syntax::symbol::symbols` items. r? @Zoxc
|
bors seems to have gotten stuck @bors try |
|
|
|
@oli-obk I think you have to use |
|
@bors retry |
bors
added a commit
that referenced
this pull request
May 8, 2019
Use `Symbol` more A `Symbol` can be equated with a string (e.g. `&str`). This involves a TLS lookup to get the chars (and a Mutex lock in a parallel compiler) and then a char-by-char comparison. This functionality is convenient but avoids one of the main benefits of `Symbol`s, which is fast equality comparisons. This PR removes the `Symbol`/string equality operations, forcing a lot of existing string occurrences to become `Symbol`s. Fortunately, these are almost all static strings (many are attribute names) and we can add static `Symbol`s as necessary, and very little extra interning occurs. The benefits are (a) a slight speedup (possibly greater in a parallel compiler), and (b) the code is a lot more principled about `Symbol` use. The main downside is verbosity, particularly with more `use syntax::symbol::symbols` items. r? @Zoxc
|
|
|
|
|
@rust-timer build ce805fd |
|
Success: Queued ce805fd with parent b92d360, comparison URL. |
|
Finished benchmarking try commit ce805fd |
|
I think github is being bugged by time travellers today |
|
One 1.4% perf improvement, many small ones (<1%) |
|
(I haven't done a full review but this does sound like something I've been wanting for a long time) |
|
The |
src/libsyntax_pos/symbol.rs
Outdated
| } | ||
|
|
||
| // Non-identifer symbols that can be referred to with syntax_pos::nisymbols::*. | ||
| NISymbols { |
petrochenkov
May 9, 2019
Contributor
"Non-identness" doesnt' really matter, entries in the Symbols { ... } block should probably just allow an optional : "non-ident" literal (with everything generated in one mod symbols).
"Non-identness" doesnt' really matter, entries in the Symbols { ... } block should probably just allow an optional : "non-ident" literal (with everything generated in one mod symbols).
nnethercote
May 9, 2019
Author
Contributor
Ah, I didn't realize that was possible. Good suggestion, I will implement it.
Ah, I didn't realize that was possible. Good suggestion, I will implement it.
Zoxc
May 10, 2019
Contributor
I'd like us to have 2 namespaces here, so if you use symbols::a you know you're getting a and not some other identifier. It also ensure there won't be any name conflicts if you add a: "b" and you want to add a later.
We could probably rename symbols to idents in that case.
I'd like us to have 2 namespaces here, so if you use symbols::a you know you're getting a and not some other identifier. It also ensure there won't be any name conflicts if you add a: "b" and you want to add a later.
We could probably rename symbols to idents in that case.
|
So, my primary concern is that we are front-loading interning of about 500 strings and do it in every compilation session even if most of them won't be actually used. Could you measure how much time the UI test suite (a lot of little programs) takes with and without these changes? |
bors
added a commit
that referenced
this pull request
May 13, 2019
Use `Symbol` more A `Symbol` can be equated with a string (e.g. `&str`). This involves a TLS lookup to get the chars (and a Mutex lock in a parallel compiler) and then a char-by-char comparison. This functionality is convenient but avoids one of the main benefits of `Symbol`s, which is fast equality comparisons. This PR removes the `Symbol`/string equality operations, forcing a lot of existing string occurrences to become `Symbol`s. Fortunately, these are almost all static strings (many are attribute names) and we can add static `Symbol`s as necessary, and very little extra interning occurs. The benefits are (a) a slight speedup (possibly greater in a parallel compiler), and (b) the code is a lot more principled about `Symbol` use. The main downside is verbosity, particularly with more `use syntax::symbol::symbols` items. r? @Zoxc
|
|
This was referenced May 13, 2019
Merged
This was referenced May 13, 2019
Merged
bors
added a commit
that referenced
this pull request
May 14, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
bors
added a commit
that referenced
this pull request
May 14, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
bors
added a commit
that referenced
this pull request
May 15, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
bors
added a commit
that referenced
this pull request
May 15, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
bors
added a commit
that referenced
this pull request
May 15, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
nnethercote
added a commit
to nnethercote/rust
that referenced
this pull request
May 21, 2019
`Symbol` received the same treatment in rust-lang#60630. Also, we can derive `PartialEq` for `InternedString`.
nnethercote
added a commit
to nnethercote/rust
that referenced
this pull request
May 21, 2019
`Symbol` received the same treatment in rust-lang#60630. Also, we can derive `PartialEq` for `InternedString`.
bors
added a commit
that referenced
this pull request
May 21, 2019
… r=<try> Remove impls for `InternedString`/string equality. `Symbol` received the same treatment in #60630. Also, we can derive `PartialEq` for `InternedString`. r? @petrochenkov
bors
added a commit
that referenced
this pull request
May 21, 2019
… r=<try> Remove impls for `InternedString`/string equality. `Symbol` received the same treatment in #60630. Also, we can derive `PartialEq` for `InternedString`. r? @petrochenkov
bors
added a commit
that referenced
this pull request
May 21, 2019
… r=<try> Remove impls for `InternedString`/string equality. `Symbol` received the same treatment in #60630. Also, we can derive `PartialEq` for `InternedString`. r? @petrochenkov
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 22, 2019
…alEq-impls, r=petrochenkov Remove impls for `InternedString`/string equality. `Symbol` received the same treatment in rust-lang#60630. Also, we can derive `PartialEq` for `InternedString`. r? @petrochenkov
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 22, 2019
…alEq-impls, r=petrochenkov Remove impls for `InternedString`/string equality. `Symbol` received the same treatment in rust-lang#60630. Also, we can derive `PartialEq` for `InternedString`. r? @petrochenkov
bors
added a commit
that referenced
this pull request
May 23, 2019
Simplify use of keyword symbols They mirror non-keyword symbols now (see #60630). `keywords::MyKeyword.name()` -> `kw::MyKeyword` `keywords::MyKeyword.ident()` -> `Ident::with_empty_ctxt(kw::MyKeyword)` (not common) `keywords::Invalid.ident()` -> `Ident::invalid()` (more common) Keywords are simply `Symbol` constants now, the `Keyword` struct is eliminated. This means `kw::MyKeyword` can now be used in `match` in particular.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
A
Symbolcan be equated with a string (e.g.&str). This involves aTLS lookup to get the chars (and a Mutex lock in a parallel compiler)
and then a char-by-char comparison. This functionality is convenient but
avoids one of the main benefits of
Symbols, which is fast equalitycomparisons.
This PR removes the
Symbol/string equality operations, forcing a lotof existing string occurrences to become
Symbols. Fortunately, theseare almost all static strings (many are attribute names) and we can add
static
Symbols as necessary, and very little extra interning occurs.The benefits are (a) a slight speedup (possibly greater in a parallel
compiler), and (b) the code is a lot more principled about
Symboluse.The main downside is verbosity, particularly with more
use syntax::symbol::symbolsitems.r? @Zoxc