I wouldn’t bother worrying about efficiency unless I knew it was a problem. Instead I would think about what makes most sense. Declaring a variable as a member means it belongs to the state of the object, and suggests it is shared across calls to the object. Declaring a variable as a local variable in a method clearly states the longevity of the variable to exist for the duration of the call, no further. It has a shorter scope than a member variable (member variables exists for the duration of the object).
Sit back and think if you need that variable to persist over time. Does your class have multiple methods, when which called, require that data to exist? If so, it sounds like a candidate for becoming a member. If not, it sounds like a candidate for becoming a local variable.
So I get you this way; you’re not very interested in software design as much as you are with performance concerns at this point - or the contrary - you want to design your software and feel unsure if your software practices will result in slow code. You want to either solve a concrete, measurable problem or you just want to learn how to squeeze every bit of performance out of your script without knowing if it’s slow or not in the first place, to proactively prevent performance rot.
So apart from the practical and logical reasons where to put variables, let’s think about what implications there are for both approaches:
Each instance of the class will consume 4 bytes extra for storing the value. If you have 1000 objects, you’ll require 4000 bytes memory to hold a float for each instance. Each object will be located “somewhere” in memory. Accessing the memory might cause a cache miss, if the memory was not already cached since before. Unfortunately I haven’t dug deep into the native side to see if the memory implicitly get cached after a call to Update. I would assume Unity still requires base class memory for normal operation so chances are the memory already is cached from prior access. I don’t know about the memory layout for subclasses in detail, but I would imagine that memory is very near the base class memory and could get cached by the CPU.
Each call to the method will reserve 4 byte stack space for the float (this memory is transient and will be freed after method call). This means 1000 objects require no extra memory for each instance. Since Unity is executing Update in the main thread, only one call is generally open at any time, so the program uses 4 bytes stack space at most. To allocate stack space, a register is typically incremented that represent the stack size. To deallocate stack space, the register is typically restored. Stack operations are generally very fast. Since the stack is almost always in use, it’s very likely to be cached when you want to read the variable.
Well, it means that having a local variable you’re constrained to not being able to store that information between calls. Likely, you’re either dealing with a constant or a query. It communicate to readers of your code that the variable is local to the method, and is not shared between methods. May result with less worries on their mind as they don’t have to trace every method it’s used in. It means that having a member variable, you’re not constrained to store the information for later use. Doing so cost (a small amount of) memory. It might be possible that cache misses are more frequent, stalling the CPU if it can’t execute out of order.
But in all seriousness, it feels like the question is slightly misplaced. If the information has to persist between method calls, what choice do you have? Besides, is this really your performance bottleneck in your program? Is it slower than comparing a short string? Is it slower than the function call in the first place? If you are genuinely interested in seeing performance comparisons, write a performance test! Create a million instances and measure how long it takes to execute both setups. Then, modify the code so it does something meaningful (i.e. has some actual calculations in the method) and see how much of a bump (or lack thereof) you get.
I’d totally place the variable where it makes logical sense, first. Once I know I have a performance issue, I’ll start attacking my code after I know which are the top offenders. If the pathfinding code is 50000 times slower than the code we discussed above, I won’t spend ages debating about “should it be local or member to make it go faster?”. I wouldn’t even spend a second thinking about that code, if it’s pathfinding that takes most of the time. Sure, then I could think about “moving a local to a member or vice versa” in pathfinding, but in all seriousness, I think it will do next to nothing.
Finally; please don’t just buy what I say as hard facts. Either go out there and read other articles/litterature to strengthen or weaken your assumptions or perform some tests yourself to see what practical, measurable, noticable effect you’ll get. Also, I may be wrong like everyone else. I don’t want to send you off misinformed because I made an error somewhere. I can reason as to why given what I know, but I don’t claim to know everything and I can’t claim that everything I’ve read from other users necessarily are hard facts (even though I often assume they are, especially in my younger years).