[aerooneqq]

View all comments

SyntaxContext is basically an index type but it is not declared through newtype_index.

r? @petrochenkov

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in coverage instrumentation.

cc @Zalathar

[petrochenkov]

#163668 has been merged, unblocking.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[petrochenkov]

Blocked on #164696.
@rustbot blocked

[rust-bors]

✌️ @aerooneqq, you can now approve this pull request!

If @petrochenkov told you to "r=me" after making some further change, then please make that change and post @bors r=petrochenkov.

View changes since this delegation.

[aerooneqq]

@bors r=petrochenkov squash msg="Declare SyntaxContext through rustc_index::newtype_index!"

[rust-bors]

🔨 14 commits were squashed into 63e2ea2.

[rust-bors]

📌 Commit 63e2ea2 has been tentatively approved by petrochenkov

It will be put into the queue for this repository once PR CI succeeds.

[rust-timer]

Note

This PR was benchmarked as part of triage of its containing rollup: triage URL.

Finished benchmarking commit (58a325d): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	3
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.3%]	15
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	3

Max RSS (memory usage)

Results (secondary -5.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.8%	[-5.8%, -5.8%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -15.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-15.5%	[-15.5%, -15.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Artifact size: 406.54 MiB -> 406.53 MiB (-0.00%)

[panstromek]

Interesting, that seems somewhat unexpected. Do we know where the improvements come from? Is this maybe because we get better niches?

[aerooneqq]

I did not expect it to affect perf at all, have no idea where those changes came from.

[panstromek]

The main diff for libc incr-patched add-fn is in malloc, and then parse_token_tree.

-4,076,687 (100.0%)  PROGRAM TOTALS


  Ir________________________  function:file

> -2,912,933 (71.5%,  71.5%)  malloc_default:???

>   -678,752 (16.6%,  88.1%)  <rustc_parse::parser::Parser>::parse_token_tree:???

>   -452,880 (11.1%,  99.2%)  pthread_mutex_trylock@@GLIBC_2.34:./nptl/./nptl/pthread_mutex_trylock.c

>   -318,240  (7.8%, 107.0%)  pthread_mutex_unlock@@GLIBC_2.2.5:./nptl/./nptl/pthread_mutex_unlock.c

>   -313,196  (7.7%, 114.7%)  tcache_bin_flush_stashed:???

>    292,428 (-7.2%, 107.5%)  <rustc_middle::query::on_disk_cache::CacheEncoder as rustc_span::SpanEncoder>::encode_span:???

>    180,227 (-4.4%, 103.1%)  <rustc_hir::hir::Ty as rustc_data_structures::stable_hash::StableHash>::stable_hash::<rustc_middle::ich::StableHashState>:???

>   -149,263  (3.7%, 106.8%)  <rustc_parse::parser::Parser>::bump:???

>   -120,038  (2.9%, 109.7%)  <rustc_attr_parsing::interface::AttributeParser>::parse_single::<rustc_ast::attr::data_structures::CfgEntry>:???

>    107,469 (-2.6%, 107.1%)  <rustc_resolve::Resolver>::resolve_crate::{closure#0}:???

For tt-muncher check, parse_token_tree is even more pronounced:

Ir__________________ 

-18,106,714 (100.0%)  PROGRAM TOTALS

--------------------------------------------------------------------------------
-- File:function summary
--------------------------------------------------------------------------------
  Ir_________________________  file:function

< -12,559,136 (69.4%,  69.4%)  ???:
   -7,093,547 (39.2%)            <rustc_parse::parser::Parser>::parse_token_tree
   -4,727,670 (26.1%)            <rustc_expand::expand::MacroExpander>::fully_expand_fragment
     -593,265  (3.3%)            <rustc_mir_transform::pass_manager::Lint<rustc_mir_transform::check_packed_ref::CheckPackedRef> as rustc_mir_transform::pass_manager::MirPass>::run_pass
      593,256 (-3.3%)            <rustc_mir_transform::check_packed_ref::CheckPackedRef as rustc_mir_transform::pass_manager::MirLint>::run_lint
      386,483 (-2.1%)            <rustc_lint::BuiltinCombinedLateLintModPass as rustc_lint::passes::LateLintPass>::check_stmt
     -363,508  (2.0%)            <rustc_lint::unused::must_use::UnusedResults as rustc_lint::passes::LateLintPass>::check_stmt
     -354,985  (2.0%)            malloc_default
     -212,568  (1.2%)            <alloc::raw_vec::RawVec<rustc_expand::mbe::macro_parser::MatcherPos>>::grow_one
      206,316 (-1.1%)            <alloc::raw_vec::RawVec<rustc_mir_transform::jump_threading::EdgeEffect>>::grow_one
      135,644 (-0.7%)            <rustc_span::hygiene::ExpnData>::hash_expn::<rustc_middle::ich::StableHashState>
      -98,338  (0.5%)            realloc

Does macro expansion use something like Option<SyntaxContext> a lot?

[nnethercote]

-2,912,933 (71.5%, 71.5%) malloc_default:???

Why is normal malloc showing up, rather than jemalloc? @Kobzol, any ideas?

[panstromek]

I don't think that's the default malloc from libc, if I understand correctly, jemalloc contains malloc_default as well: https://github.com/jemalloc/jemalloc/blob/9aa5b1371973eaea2bb9a035c3686bf87b07fd3a/src/jemalloc.c#L771

[panstromek]

oh, SyntaxContext is embedded into Span, is it possible that the niche allows us to avoid some of the size checks when constructing spans?

[panstromek]

I tried to remove the niche in #164803, and that shows no changes, so this is probably something else.