Record type-dependent defs in item signatures

[mu001999]

View all comments

Tracking: #156711

Attempt to record type-dependent defs in ItemCtxt, and expose recorded results through new queries.

TODO:

• Find a correct approach to implement this
• Try using this mechanism in dead-code analysis to lint unused associated types (replace Lint unused associated types #148654)

cc @fmease

[mu001999]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4ba8cfc (4ba8cfc85bee82c50ae59d2be48214d1effdea61, parent: 042c759f774872cf2f94c6685ce87e24c046c722)

[rust-timer]

Finished benchmarking commit (4ba8cfc): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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)	1.7%	[0.1%, 4.8%]	181
Regressions ❌ (secondary)	1.6%	[0.0%, 9.6%]	136
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[0.1%, 4.8%]	181

Max RSS (memory usage)

Results (primary 2.5%, secondary 2.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.5%	[0.7%, 6.4%]	88
Regressions ❌ (secondary)	3.3%	[0.8%, 10.1%]	43
Improvements ✅ (primary)	-1.3%	[-1.3%, -1.3%]	1
Improvements ✅ (secondary)	-1.8%	[-3.8%, -0.5%]	3
All ❌✅ (primary)	2.5%	[-1.3%, 6.4%]	89

Cycles

Results (primary 5.0%, secondary 5.1%)

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

	mean	range	count
Regressions ❌ (primary)	5.0%	[1.6%, 9.1%]	69
Regressions ❌ (secondary)	5.5%	[2.0%, 15.1%]	36
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	2
All ❌✅ (primary)	5.0%	[1.6%, 9.1%]	69

Binary size

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

Bootstrap: 516.236s -> 511.162s (-0.98%)
Artifact size: 400.65 MiB -> 400.93 MiB (0.07%)

[mu001999]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: c6f95a5 (c6f95a5f957de19fe5b741d41eb78661f4dec6eb, parent: 76dfce2cb2d3f7b7f34d62e6ffe044f7e7d76948)

[rust-timer]

Finished benchmarking commit (c6f95a5): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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)	1.7%	[0.1%, 4.9%]	180
Regressions ❌ (secondary)	1.6%	[0.1%, 9.5%]	134
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.3%]	2
All ❌✅ (primary)	1.7%	[0.1%, 4.9%]	180

Max RSS (memory usage)

Results (primary 2.4%, secondary 3.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.4%	[0.7%, 6.7%]	89
Regressions ❌ (secondary)	3.3%	[0.7%, 9.8%]	37
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.8%	[-5.8%, -5.8%]	1
All ❌✅ (primary)	2.4%	[0.7%, 6.7%]	89

Cycles

Results (primary 4.9%, secondary 6.0%)

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

	mean	range	count
Regressions ❌ (primary)	4.9%	[1.2%, 9.4%]	72
Regressions ❌ (secondary)	6.2%	[2.1%, 14.8%]	32
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	4.9%	[1.2%, 9.4%]	72

Binary size

Results (primary -0.1%, secondary -0.1%)

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.1%	[-0.1%, -0.0%]	37
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	21
All ❌✅ (primary)	-0.1%	[-0.1%, -0.0%]	37

Bootstrap: 511.359s -> 527.166s (3.09%)
Artifact size: 400.66 MiB -> 400.87 MiB (0.05%)

[mu001999]

I think the main regression is because new queries, let me revert codes about dead-code and re-run the perf later.

[mu001999]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4c1d7ca (4c1d7ca0ecf69fcdcb18edeb53ad0bebb1c72fa2, parent: 0cf96812614b8250543d749629867b36f2757f4d)

[rust-timer]

Finished benchmarking commit (4c1d7ca): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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)	1.7%	[0.1%, 4.7%]	176
Regressions ❌ (secondary)	1.6%	[0.1%, 9.5%]	127
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[0.1%, 4.7%]	176

Max RSS (memory usage)

Results (primary 2.2%, secondary 3.3%)

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

	mean	range	count
Regressions ❌ (primary)	2.2%	[0.6%, 6.5%]	75
Regressions ❌ (secondary)	3.6%	[0.6%, 10.3%]	31
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.3%	[-6.3%, -6.3%]	1
All ❌✅ (primary)	2.2%	[0.6%, 6.5%]	75

Cycles

Results (primary 4.7%, secondary 6.1%)

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

	mean	range	count
Regressions ❌ (primary)	4.7%	[1.4%, 9.1%]	70
Regressions ❌ (secondary)	6.4%	[2.3%, 14.3%]	32
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	4.7%	[1.4%, 9.1%]	70

Binary size

Results (primary -0.0%, secondary -0.0%)

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.0%	[-0.0%, -0.0%]	4
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	2
All ❌✅ (primary)	-0.0%	[-0.0%, -0.0%]	4

Bootstrap: 512.762s -> 514.136s (0.27%)
Artifact size: 400.63 MiB -> 400.91 MiB (0.07%)

[mu001999]

The current implementation works for assoc types in lint dead_code. However, at least for now, this way seems would cause a large performance regression (without the change of dead_code lint).

I’m not sure whether this is mainly due to adding more layers of queries, or due to recording type_dep_defs in ItemCtxt.

Hi @fmease, do you have any thoughts on the current implementation and the performance regression? For now, the main change is that it adds several query variants that additionally return type_dep_defs (see this diff).