X[Y] performance vs x = X[Y]

This is a question that goes out to anyone that has sufficient insight to answer it. Can array access performance ever be a drag compared to using a local variable?

If Y is a non-changing integer and X[Y] is a value that doesn't change during a certain coarse of time there would be two primary attitudes towards using it:

1: X[Y] is assumed to be so efficient that even with 1000 accesses it's just not worth it to optimize towards a local variable.
2: X[Y] is slower than a local variable access and at a certain threshold it's more efficient to store it temporarily.

The easiest answer would be if the first option holds true, in which case X[Y] can be used without thought. But it seems more likely to me that the second option has to be correct, although at which threshold? Should I do it at 5 accesses? At 10? 50? 500?

I think that an answer to this question would be useful to several people considering how arrays are being used more than ever. Does anyone have the time and method to give a trustworthy answer to this?

Another related, almost identical, but nevertheless interesting question is the exact X[Y] performance vs reading a single variable Z.

I'm pretty sure most languages have an optimized way of using local variables and since I assume JASS probably compiles into direct C++ code instead of straight to machine code it use C++'s optimization for local variables. And considering how there is processing involved in looking up arrays and finding the root of the array is not optimized like a local variable I think you'll find the threshold quite early.

I am sorry to point this out to you, but your answer is based on mere assumptions, some of which I know to be completely nonsense. JASS does NOT compile into any kind of C++ code, it does NOT use C++'s optimization for local variables.

Posting such pure (and WRONG) guesses when I request, and I quote, "a trustworthy answer" seems rather inappropriate.

x: get var - 1 op
x[y]: get var, set arg, get array - 3 ops
local x = x[y]: declare var, get var, set arg, get array, set var - 5 ops

times used - no cache ops - cache ops
0 - 0 - 5
1 - 3 - 6
2 - 6 - 7
3 - 9 - 8
4 - 12 - 9
5 - 15 - 10

So, assuming all bytecodes take about the same time to execute, call it for sure worth it greater than 5. Personally I use a var for >=3 uses, just because it's easier for me to read at that point.
If you just want to look at hash table uses then it's 2 for no cache and 1 for cache, with some unknown creation cost.
It's easy to benchmark with the japi natives (someone remind me to overwrite a stock native with these) but there are a lot of possible weirding out factors so someone with an actual map should do it.

I knew about the number of bytecodes from on of your previous posts. I did however have no idea to which extent the number of ops take roughly equal time to execute, but I guess it's actually a sensible assumption.

In any case the actual cost in terms of cpu power is still somewhat unknown, correct?

Readability isn't an issue as the arrays I am talking about are, unsurprisingly, underlying and hidden. For now I will adopt the habit of using caching only whenever a noticable amount of re-use of the same variable happens. X[Y] is already such a small operation that worthwhile performance gain for it can only happen if very large quantities of it is optimized in one swipe, such as in loops.

Are you implementing a loop invariant lifter?

Not at all. :)

Can't even think of anything like that worth doing.