ci: add step to disable Spotlight indexing on macOS

[xtqqczze]

No description provided.

[rustbot]

r? @sayantn

rustbot has assigned @sayantn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[xtqqczze]

Suggested change

	- name: Disable Spotlight indexing
	- name: Disable Spotlight indexing (macOS)

[bjorn3]

What is the reason for doing this?

[xtqqczze]

What is the reason for doing this?

There may be a reduction on run time for the job

[bjorn3]

The CI time differences seem to be within noise.

[xtqqczze]

It was worth a try, there were significant reductions for uutils/coreutils#10453

[sayantn]

Any more updates on this? Also, just a curiosity, what does this exactly do? I am guessing it disables some kind of filesystem indexing, which can indeed help with perf, but stdarch is a small enough repo that it might not matter at the end of the day.

[rustbot]

☔ The latest upstream changes (possibly #2062) made this pull request unmergeable. Please resolve the merge conflicts.

[clado]

not the original author, but I did some research on this.

This actions/runner images discussion probably best describes the issue & the motivation for turning off spotlight indexing. It seems that spotlight can use up to 45% of worker CPU indexing files, something that can happen right on startup (and presumably later into the CI run if metadatastore decides to reindex later in the run, based on changes to the filesystem?) and take multiple minutes (something that presumably varies based on filesystem size and does indeed seem to cause severe delays for some builds).

In a turn of events that I find very silly, the github actions folks themselves have turned off spotlight indexing multiple times on their machines throughout the project's history, but each time turned it back on after user complaints. X) Here are the two that I found before I stopped looking:

• Late-2020: turned off, user complaint, turned back on
• this time last year: turned off, user complaint, turned back on

the problems being that many Apple tools require an index to function (most notably from the above issues: "finding a version of xcode to use via mdfind")

If std::arch is not really using Xcode or any other macos operating system tooling and is instead largely using the macos runners to test architecture-specific intrinsics, it's potentially perfectly suited to take advantage of the speed boost of turning off metadata services to no ill-effects. The question is whether the (re)indexing is intrusive enough to result in any time savings, and it seems like in this case it might not be, as both sayantn and bjorn3 have pointed out?

(makes me wonder whether it'd be worthwhile in rust-lang/rust though, hence my interest. 👀)