GetComponent iterates over each component on the selected GameObject until it finds one that matches the query- this is typically about a half dozen objects, or less. GetComponentInParent iterates over all components on the current GameObject, then all of the components on the parent GameObject, that that GameObject’s parent, etc… until it reaches the root. This can be dozens and dozens of components in total, but usually not more than a hundred. Likewise for GetComponentInChildren, but going in the other direction.
All of these checks are type comparisons, which are pretty fast, and the number of objects being iterated over are pretty small, but developers try to make a habit of “caching references” to various scripts if they need to be accessed more than once. You do this by defining a private field of the type of component you want to reference, then assigning the GetComponent result to that field in Awake or Start.
public class SomeComponent : MonoBehaviour
{
private SomeOtherComponent someField;
private void Awake()
{
someField = GetComponent<SomeOtherComponent>();
}
private void Start()
{
someField.someStringProperty = "New String";
}
}
… or by making the field public, or adding the SerializeField attribute to it, so that it shows up as a reference in the inspector and you can just pick another component in the scene to use there.
GameObject.Find iterates over all active objects in the whole scene, doing string comparisons on the name of each. GameObject.FindWithTag is the same, but with the tag instead of the name, GameObject.FindGameObjectsWithTag is the same but returns all results in an array. String comparisons aren’t really cheap, especially when doing potentially hundreds or thousands of them at once, and “active GameObjects in the scene” tends to be a far larger number than “components in a given GameObject hierarchy”. Unless you’re making editor scripts, there are always more effective ways of keeping track of objects than doing scene searches, so I personally consider using GameObject.Find, or anything to do with tags, to be a failure in planning rather than a viable strategy.
For something resembling completion’s sake, since I’m going over most of the important search functions, Resources.FindObjectsOfTypeAll is a search by type instead of string, but it includes assets in the project files as well, so it could be thousands and thousands of results, making it even more painful than GameObject.Find unless the scene is massive.
Anyway, even the slowest of these operations isn’t going to be a big deal if you don’t do it in Update or a coroutine- do it once, and cache the results if you need to (as shown with GetComponent in the example), and you should be fine. If you need up-to-date references more often than that, then you’d be better off setting up a different system for obtaining it- updating the reference in a manager of some sort so that multiple scripts can access that value whenever they want, or setting up events to alert listeners when the reference changes, etc…
Your other questions are answered better by going through the beginner Scripting section on the Unity Learn site. I highly recommend sitting through all of the tutorials up through Intermediate before even touching Unity honestly- the GetComponent cached reference example above should show how to do most of what you were asking though.
