yeah, learning the 'language' of programming, C, DSP all at once is tricky, but unfortunately programming is about precision, so its pretty vital ... you'll get there, the more you do/read the clearer it becomes.
also bare in mind Axoloti is deliberately hiding 'non essential' details, so that can for some subjects add more complication ... of course, for other topics, it simplifies things immensely.
ok, so local data , is a declarative section, its a good idea to get really clear in C the distinction between declaration and code.
for the purpose you are discussing the difference is, do you have to allocate the int32_t (yes its a type too, you wont find in a general C book) when allocating the object (which more correctly is a class, and your defining in local data) or when the function is called (k/s-rate). really neither is 'quicker' as the amount of memory is calculate upfront by the compiler... and even this is not quite the case, since the dsp functions are 'attempted' to be in-lined.
from a 'theoretically' (i.e. your book) from a C standpoint there is no difference, the code should execute at the same speed. (or the different would be ridiculously small)
BUT... if it is quicker, then I would say its down to the compilers optimizer.
what could happen, in the s-rate example, is that the optimizer spots that the variable is only used in one place, and so is able to allocate a register to hold the result, rather than use a memory location (slower).
(note: I say could, because theoretically the optimizer could (shoud?) be intelligent enough to do the same in both scenarios, only checking the assembly output can tell you the truth)
so here is your problem... understanding optimizers is very difficult, even for very experienced programmers... often what you think is going to happen doesn't and its quite possible to try to optimize for a compiler and make it worst! ... or even when a new version of the compiler is introduced, and your optimisation is now invalid.
( to optimize really well, you have to really a grounding in assembly, compiler technology, optimizers)
so how do most programmers 'get around this'...
well the optimizers are really very intelligent (and constantly improving) so generally you don't care about them... in most programming contexts this is enough, and there are more gains to be made in your own algorithms than squeezing the optimizer.
but my advice to programmers is simple, make your code express your intent as closely as possible, in as simple way as possible... the hope is, if its easy to understand, and in a 'common approach' then the optimizer will be more likely to recognise.
so in your example the reason you should have been declaring in s-rate and not local data is because that is where you need the data... you don't need it in a broader context, and its generally good programming practice to keep the 'scope' of variables as limited as possible (for a variety of reasons, that you can read up on )
reading this back, this seems like a really convoluted reply, but unfortunately, once you get into optimizers/in-lining, its really a whole new level... one that many C programmers with years of experience don't even venture into.
(but of course, are quite relevant to DSP programming on a CPU with very limited resources... if you did this on a PC, say for aVST, , you'd likely 'get away' with not hearing about any of this stuff)