Perf improvements for effective visibility calculating

[Bryanskiy]

related to #102026
r? @petrochenkov

[petrochenkov]

If the update operation is a hotspot you need to get rid of all the helper methods it calls and reimplemented it from scratch as a single operation.

What I don't like right now:

• Two nested loops over levels, the logic should go over the previous and parent effective visibilities once and do the minimal number of comparisons.
• EffectiveVisibility::update is only called once from AccessLevels::update and can be inlined/removed.
• Double search in the map self.get_effective_vis(id) + self.map.insert(id, ...), you could use self.map.entry(...) instead.

It may also be useful to go back to using Option<Visibility>es in EffectiveVisibility, in that case fully private visibilities (None) can be compared without is_at_least.
All of this needs benchmarking though.

Also, as I said in #102026 (comment) it's possible that update itself is not the main reason for the slowdown, it's possible that the reason is that we call it for items for which we shouldn't call it at all.
@rustbot author

[Bryanskiy]

@rustbot ready

[Bryanskiy]

@rustbot ready

I cannot start a perf run until this PR is rebased.
@rustbot author

@rustbot ready

@rustbot ready

r=me after squashing commits.
@rustbot author

@rustbot ready

@bors r+

📌 Commit a9447bb has been approved by petrochenkov

It is now in the queue for this repository.

⌛ Testing commit a9447bb with merge a5406fe...

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing a5406fe to master...

Finished benchmarking commit (a5406fe): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.5%, -0.3%]	6
Improvements ✅ (secondary)	-0.6%	[-2.0%, -0.2%]	22
All ❌✅ (primary)	-0.4%	[-0.5%, -0.3%]	6

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-	-	0

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²