[PERF EXPERIMENT] Use a SmallVec for item paths (Vec<Symbol>s)

[yotamofek]

Checked the average size of all dropped ItemPaths when x perf is run, the average is 3.1 elements.
So use a SmallVec with room for 4 inline elems, since it takes up 24 bytes for either 3 or 4.

[yotamofek]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 6b15d7d (6b15d7d71225907d86d254aad345c7f8526ab55e, parent: cb46fbb8c6ea799c6fba9188ed889275c35a8c28)

[rust-timer]

Finished benchmarking commit (6b15d7d): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	1

Max RSS (memory usage)

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

Cycles

Results (secondary -2.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)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 517.707s -> 517.743s (0.01%)
Artifact size: 400.82 MiB -> 400.85 MiB (0.01%)

[yotamofek]

@GuillaumeGomez probably not worth it, right?

[GuillaumeGomez]

Not really indeed. ^^'

Isn't there a way to have a similar approach without the need for all the conversions?

[yotamofek]

We could just use SmallVec<[Symbol; 4]> directly (or through an alias) instead of new-typing it, and that'll allow us to get rid of some .into()s.
But then if we do have a newtype, we could do nice things such as give it inherent methods, e.g. for joining the path parts with :: etc...

[GuillaumeGomez]

Since we have deref implemented already, do we need to have this IntoIterator implementation?

View changes since the review

[GuillaumeGomez]

Hum... Maybe build a bit more on top of this to see if we can get more out of this newtype? If the performance improvement is bigger, it's much simpler to accept this newtype with its implementations.