I'm programming in C for RAM limited embedded microcontroller with RTOS.
I regularly break my code to short functions, but every function calling require to more stack memory.
Every task needs his stack, and this is one of the significant memory consumers in the project.
Is there an alternative to keep the code well organized and readable, still preserve the memory?
Try to make the call stack flatter, so instead of a() calling b() which calls c() which calls d(), have a() call b(), c(), and d() itself.
If a function is only referenced once, mark it inline (assuming your compiler supports this).
There are 3 components to your stack usage:
Function Call return addresses
Function Call parameters
automatic(local) variables
The key to minimizing your stack usage is to minimize parameter passing and automatic variables. The space consumption of the actual function call itself is rather minimal.
Parameters
One way to address the parameter issue is to pass a structure (via pointer) instead of a large number of parameters.
foo(int a, int b, int c, int d)
{
...
bar(int a, int b);
}
do this instead:
struct my_params {
int a;
int b;
int c;
int d;
};
foo(struct my_params* p)
{
...
bar(p);
};
This strategy is good if you pass down a lot of parameters. If the parameters are all different, then it might not work well for you. You would end up with a large structure being passed around that contains many different parameters.
Automatic Variables (locals)
This tend to be the biggest consumer of stack space.
Arrays are the killer. Don't define arrays in your local functions!
Minimize the number of local variables.
Use the smallest type necessary.
If re-entrancy is not an issue, you can use module static variables.
Keep in mind that if you're simply moving all your local variables from local scope to module scope, you have NOT saved any space. You traded stack space for data segment space.
Some RTOS support thread local storage, which allocates "global" storage on a per-thread basis. This might allow you to have multiple independent global variables on a per task basis, but this will make your code not as straightforward.
In the event you can spare a lot of main memory but have only a small shred of stack, I suggest evaluating static allocations.
In C, all variables declared inside a function are "automatically managed" which means they're allocated on the stack.
Qualifying the declarations as "static" stores them in main memory instead of on the stack. They basically behave like global variables but still allow you to avoid the bad habits that come with overusing globals. You can make a good case for declaring large, long-lived buffers/variables as static to reduce pressure on the stack.
Beware that this doesn't work well/at all if your application is multithreaded or if you use recursion.
Turn on optimization, specifically aggressive inlining. The compiler should be able to inline methods to minimize calls. Depending on the compiler and the optimization switches you use, marking some methods as inline may help (or it may be ignored).
With GCC, try adding the "-finline-functions" (or -O3) flag and possibly the " -finline-limit=n" flag.
One trick that I read somewhere inorder to evaluate the stack requirements of the code in an embedded setup is to fill the stack space at the onset with a known pattern(DEAD in hex being my favorite) and let the system run for a while.
After a normal run, read the stack space and see how much of the stack space has not been replaced during the course of operation. Design so as to leave atleast 150% of that so as to tackle all obsure code paths that might not have been exercised.
Can you replace some of your local variables by globals?
Arrays in particular can eat up stack.
If the situation allows you to share some globals between some those between functions,
there is a chance you can reduce your memory foot print.
The trade off cost is increased complexity, and greater risk of unwanted side effects between functions vs a possibly smaller memory foot print.
What sort of variables do you have in your functions?
What sizes and limits are we talking about?
Depending on your compiler, and how aggressive your optimisation options are, you will have stack usage for every function call you make. So to start with you will probably need to limit the depth of your function calls.
Some compilers do use jumps rather than branches for simple functions which will reduce stack usage. Obviously you can do the same thing by using, say, an assembler macro to jump to your functions rather than a direct function call.
As mentioned in other answers, inlining is one option available although that does come at the cost of greater code size.
The other area that eats stack is the local parameters. This area you do have some control over. Using (file level) statics will avoid stack allocation at the cost of your static ram allocation. Globals likewise.
In (truly) extreme cases you can come up with a convention for functions that uses a fixed number of global variables as temporary storage in lieu of locals on the stack. The tricky bit is making sure that none of the functions that use the same globals ever get called at the same time. (hence the convention)
If you need to start preserving stack space you should either get a better compiler or more memory.
Your software will typically grow (new features,...) , so if you have to start a project by thinking about how to preserve stack space it's doomed from the beginning.
Yes, an RTOS can really eat up RAM for task stack usage. My experience is that as a new user of an RTOS, there's a tendency to use more tasks than necessary.
For an embedded system using an RTOS, RAM can be a precious commodity. To preserve RAM, for simple features it can still be effective to implement several features within one task, running in round-robin fashion, with a cooperative multitasking design. Thus reduce total number of tasks.
I think you may be imagining a problem which doesnt exist here. Most compilers don't actually do anything when they "allocate" automaticic variables on the stack.
The stack is allocated before "main()" is executed. When you call function b() from function a() the address of the storage area immediately after the last variable used by a is passed to b(). This becomes the start of b()'s stack if b() then calls function c() then c's stack starts after the last automatic variable defined by b().
Note that the stack memory is already there and allocated, that no initialisation takes place and the only processing involved is passing a stack pointer.
The only time this becomes a problem would be where all three functions use large amounts of storage the stack then has to accomadate the memory of all three functions. Try to keep functions which allocate large amounts of storage at the bottom of the call stack i.e. dont call another function from them.
Another trick for memory constained systems is to split of the memory hogging parts of a function into separate self contained functions.
Related
The code:
//function prototype
void efg(int x);
//mother functioon
abc()
{
int a=1;
efg(a);
}
When efg is executing, changing x is not changing a then we have a copy of a. But what if we dont want a copy to use memory efficiently?
One way is to pass the a's pointer &a.
I have som constrants:
Don't want to pass anything. Since I have about 20 variable.
Don't want it's pointer's. I want direct access to it.
Dont want to being globally static.
Reluctant to use Heap dynamic allocation since it's embedded also it forces me to use pointer's instead of direct access.
I want my sub function (efg) be able to use the mother function's variable (a in abc) .It means efg being able to access a directly. Why not? Also I want a being being freed after abc execution finishes, since in the way explained the variables are in stack they will freed after function finishes.
The exact problem is: sub_functions initiate some structures in the memory. After sub function is finihed its job (CPU returns to mother function) the memories must be staying untouched untill the mother function finishes (CPU return to main) and here the memory must being freed.
My best dreaming solution is to use extern variable declare to use mother function stack in sub routine.
Don't want to pass anything. Since I have about 20 variable.
I hope you aren't planning to pass 20 variables to a function or you need to start placing related variables together in the same struct. If you have 20 variables total, well what does that have to do with anything?
Don't want it's pointer's. I want direct access to it.
That doesn't make any sense without a rationale why you want direct access. Indirect access vs direct access is such a minor performance difference that one shouldn't even bother considering it. Manually optimize when you actually have real time constraints or bottlenecks, don't optimize just for the heck of it.
If you worry about performance, then one sensible approach is to use small functions with internal linkage that will surely be inlined by the compiler. Note however that inlining is an execution speed over program size optimization.
Dont want to being globally static.
That's kind of contradicting, I assume you mean declared with static storage class specified but declared at file scope. Using such variables may or may not be valid design depending on use-case. For single core embedded systems, there's not really anything wrong with such variables.
Reluctant to use Heap dynamic allocation since it's embedded also it forces me to use pointer's instead of direct access.
Yes heap allocation should be avoided for multiple reasons in such systems. I wrote a summary of all the problems here: Why should I not use dynamic memory allocation in embedded systems? However, avoiding indirect access is not a valid reason.
The exact problem is: sub_functions initiate some structures in the memory. After sub function is finihed its job (CPU returns to mother function) the memories must be staying untouched untill the mother function finishes (CPU return to main) and here the memory must being freed.
So that's solved by declaring the variables as local, on the stack, then pass its address to the other function. If you don't want any other part of the program to touch that memory in the meantime, then simply refrain from writing code which does that...
Summary: don't state a bunch of ultimatums out of the blue, for which you can't sensibly argue in favour for or against. It's pretty clear that you have limited experience of program design, let alone manual code optimization. So for now the best thing you can do is to write code as readable as possible, following well-known best practices (const correctness, private encapsulation etc etc). Because readable code also tends to be efficient, bug-free code. Whereas needlessly contrived and complex code tends to be slow, buggy and hard to maintain.
Like we do with macros:
#undef SOMEMACRO
Can we also undeclare or delete the variables in C, so that we can save a lot of memory?
I know about malloc() and free(), but I want to delete the variables completely so that if I use printf("%d", a); I should get error
test.c:4:14: error: ‘a’ undeclared (first use in this function)
No, but you can create small minimum scopes to achieve this since all scope local variables are destroyed when the scope is exit. Something like this:
void foo() {
// some codes
// ...
{ // create an extra minimum scope where a is needed
int a;
}
// a doesn't exist here
}
It's not a direct answer to the question, but it might bring some order and understanding on why this question has no proper answer and why "deleting" variables is impossible in C.
Point #1 What are variables?
Variables are a way for a programmer to assign a name to a memory space. This is important, because this means that a variable doesn't have to occupy any actual space! As long as the compiler has a way to keep track of the memory in question, a defined variable could be translated in many ways to occupy no space at all.
Consider: const int i = 10; A compiler could easily choose to substitute all instances of i into an immediate value. i would occupy 0 data memory in this case (depending on architecture it could increase code size). Alternatively, the compiler could store the value in a register and again, no stack nor heap space will be used. There's no point in "undefining" a label that exists mostly in the code and not necessarily in runtime.
Point #2 Where are variables stored?
After point #1 you already understand that this is not an easy question to answer as the compiler could do anything it wants without breaking your logic, but generally speaking, variables are stored on the stack. How the stack works is quite important for your question.
When a function is being called the machine takes the current location of the CPU's instruction pointer and the current stack pointer and pushes them into the stack, replacing the stack pointer to the next location on stack. It then jumps into the code of the function being called.
That function knows how many variables it has and how much space they need, so it moves the frame pointer to capture a frame that could occupy all the function's variables and then just uses stack. To simplify things, the function captures enough space for all it's variables right from the start and each variable has a well defined offset from the beginning of the function's stack frame*. The variables are also stored one after the other.
While you could manipulate the frame pointer after this action, it'll be too costly and mostly pointless - The running code only uses the last stack frame and could occupy all remaining stack if needed (stack is allocated at thread start) so "releasing" variables gives little benefit. Releasing a variable from the middle of the stack frame would require a defrag operation which would be very CPU costly and pointless to recover few bytes of memory.
Point #3: Let the compiler do its job
The last issue here is the simple fact that a compiler could do a much better job at optimizing your program than you probably could. Given the need, the compiler could detect variable scopes and overlap memory which can't be accessed simultaneously to reduce the programs memory consumption (-O3 compile flag).
There's no need for you to "release" variables since the compiler could do that without your knowledge anyway.
This is to complement all said before me about the variables being too small to matter and the fact that there's no mechanism to achieve what you asked.
* Languages that support dynamic-sized arrays could alter the stack frame to allocate space for that array only after the size of the array was calculated.
There is no way to do that in C nor in the vast majority of programming languages, certainly in all programming languages that I know.
And you would not save "a lot of memory". The amount of memory you would save if you did such a thing would be minuscule. Tiny. Not worth talking about.
The mechanism that would facilitate the purging of variables in such a way would probably occupy more memory than the variables you would purge.
The invocation of the code that would reclaim the code of individual variables would also occupy more space than the variables themselves.
So if there was a magic method purge() that purges variables, not only the implementation of purge() would be larger than any amount of memory you would ever hope to reclaim by purging variables in your program, but also, in int a; purge(a); the call to purge() would occupy more space than a itself.
That's because the variables that you are talking about are very small. The printf("%d", a); example that you provided shows that you are thinking of somehow reclaiming the memory occupied by individual int variables. Even if there was a way to do that, you would be saving something of the order of 4 bytes. The total amount of memory occupied by such variables is extremely small, because it is a direct function of how many variables you, as a programmer, declare by hand-typing their declarations. It would take years of typing on a keyboard doing nothing but mindlessly declaring variables before you would declare a number of int variables occupying an amount of memory worth speaking of.
Well, you can use blocks ({ }) and defining a variable as late as possible to limit the scope where it exists.
But unless the variable's address is taken, doing so has no influence on the generated code at all, as the compiler's determination of the scope where it has to keep the variable's value is not significantly impacted.
If the variable's address is taken, failure of escape-analysis, mostly due to inlining-barriers like separate compilation or allowing semantic interpositioning, can make the compiler assume it has to keep it alive till later in the block than strictly neccessary. That's rarely significant (don't worry about a handful of ints, and most often a few lines of code longer keeping it alive are insignificant), but best to keep it in mind for the rare case where it might matter.
If you are that concerned about the tiny amount of memory that is on the stack, then you're probably going to be interested in understanding the specifics of your compiler as well. You'll need to find out what it does when it compiles. The actual shape of the stack-frame is not specified by the C language. It is left to the compiler to figure out. To take an example from the currently accepted answer:
void foo() {
// some codes
// ...
{ // create an extra minimum scope where a is needed
int a;
}
// a doesn't exist here
}
This may or may not affect the memory usage of the function. If you were to do this in a mainstream compiler like gcc or Visual Studio, you would find that they optimize for speed rather than stack size, so they pre-allocate all of the stack space they need at the start of the function. They will do analysis to figure out the minimum pre-allocation needed, using your scoping and variable-usage analysis, but those algorithms literally wont' be affected by extra scoping. They're already smarter than that.
Other compilers, especially those for embedded platforms, may allocate the stack frame differently. On these platforms, such scoping may be the trick you needed. How do you tell the difference? The only options are:
Read the documentation
Try it, and see what works
Also, make sure you understand the exact nature of your problem. I worked on a particular embedded project which eschewed the stack for everything except return values and a few ints. When I pressed the senior developers about this silliness, they explained that on this particular application, stack space was at more of a premium than space for globally allocated variables. They had a process they had to go through to prove that the system would operate as intended, and this process was much easier for them if they allocated everything up front and avoided recursion. I guarantee you would never arrive at such a convoluted solution unless you first knew the exact nature of what you were solving.
As another solution you could look at, you could always build your own stack frames. Make a union of structs, where each struct contains the variables for one stack frame. Then keep track of them yourself. You could also look at functions like alloca, which can allow for growing the stack frame during the function call, if your compiler supports it.
Would a union of structs work? Try it. The answer is compiler dependent. If all variables are stored in memory on your particular device, then this approach will likely minimize stack usage. However, it could also substantially confuse register coloring algorithms, and result in an increase in stack usage! Try and see how it goes for you!
Is dividing the work into 5 functions as opposed to one big function more memory efficient in C since at a given time there are fewer variables in memory, as the stack-frame gets deallocated more often? Does it depend on the compiler, and optimization? if so in what compilers is it faster?
Answer given there are a lot of local variables and the stack frames comes from a centralized main and not created on the top of each other.
I know other advantages of breaking out the function into smaller functions. Please answer this question, only in respect to memory usage.
It might reduce "high water mark" of stack usage for your program, and if so that might reduce the overall memory requirement of the program.
Yes, it depends on optimization. If the optimizer inlines the function calls, you might well find that all the variables of all the functions inlined are wrapped into one big stack frame. Any compiler worth using is capable of inlining[*], so the fact that it can happen doesn't depend on compiler. Exactly when it happens, will differ.
If your local variables are small, though, then it's fairly rare for your program to use more stack than has been automatically allocated to you at startup. Unless you go past what you're given initially, how much you use makes no difference to overall memory requirements.
If you're putting great big structures on the stack (multiple kilobytes), or if you're on a machine where a kilobyte is a lot of memory, then it might make a difference to overall memory usage. So, if by "a lot of local variables" you mean few dozen ints and pointers then no, nothing you do makes any significant difference. If by "a lot of local variables" you mean a few dozen 10k buffers, or if your function recurses very deep so that you have hundreds of levels of your few dozen ints, then it's a least possible it could make a difference, depending on the OS and configuration.
The model that stack and heap grow towards each other through general RAM, and the free memory in the middle can be used equally by either one of them, is obsolete. With the exception of a very few, very restricted systems, memory models are not designed that way any more. In modern OSes, we have so-called "virtual memory", and stack space is allocated to your program one page at a time. Most of them automatically allocate more pages of stack as it is used, up to a configured limit that's usually very large. A few don't automatically extend stack (Symbian last I used it, which was some years ago, didn't, although arguably Symbian is not a "modern" OS). If you're using an embedded OS, check what the manual says about stack.
Either way, the only thing that affects total memory use is how many pages of stack you need at any one time. If your system automatically extends stack, you won't even notice how much you're using. If it doesn't, you'll need to ensure that the program is given sufficient stack for its high-water mark, and that's when you might notice excessive stack use.
In short, this is one of those things that in theory makes a difference, but in practice that difference is almost always insignificant. It only matters if your program uses massive amounts of stack relative to the resources of the environment it runs in.
[*] People programming in C for PICs or something, using a C compiler that is basically a non-optimizing assembler, are allowed to be offended that I've called their compiler "not worth using". The stack on such devices is so different from "typical" systems that the answer is different anyway.
I think in most cases the area of memory allocated for the stack (for the entire program) remains constant. The amount in use will change based on the depth of call stack and that amount would be less when fewer variables are used (but note that function calls push the return address and stack pointer also).
Also it depends on how the functions are called. If two functions are called in series, for example, and the stack of the first is popped before the call to the second, then you'll be using less of the stack..but if the first function calls the second then you're back to where you were with one big function (plus the function call overhead).
There's no memory allocation on stack - just moving the stack pointer towards next value. While stack size itself is predefined. So there's no difference in memory usage (apart of situations when you get stack overflow).
Yes, in the same vein that using a finer coat of paint on a jet plane increases its aerodynamic properties. Ok, that's a bad analogy, but the point is that if there is ever a question of making things clear and telegraphic or trying to use more functions, go with telegraphic. In most cases these are not mutually exclusive anyway as the beginners tend to give subroutines or functions too much to do.
In terms of memory I think that if you are truly splitting up up work (f, then g, then h) then you will see some minute available memory increases but if these are interdependent then you will not.
As #Joel Burget says, memory management is not really a consideration in code structuring.
Just my take.
Splitting a huge function into smaller ones does have its benefits, among them is potentially more optimized memory usage.
Say, you have this function.
void huge_func(int input) {
char a[1024];
char b[1024];
// do something with input and a
// do something with input and b
}
And you split it to two.
void func_a(int input) {
char a[1024];
// do something with input and a
}
void func_b(int input) {
char b[1024];
// do something with input and b
}
Calling huge_func will take at least 2048 bytes of memory, and calling func_a then func_b achieves the same outcome with about half less memory. However, if inside func_a you call func_b, the amount of memory used is about the same as huge_func. Essentially, as what #sje397 wrote.
I might be wrong to say this but I do not think there is any compiler optimization that could help you reduce the usage of stack memory. I believe the layout of stack memory must ensure that sufficient memory is reserved for all declared variables, whether used or not.
If i have a test.c file with the following
#include ...
int global = 0;
int main() {
int local1 = 0;
while(1) {
int local2 = 0;
// Do some operation with one of them
}
return 0;
}
So if I had to use one of this variables in the while loop, which one would be preferred?
Maybe I'm being a little vague here, but I want to know if the difference in time/space allocation is actually relevant.
If you are wondering whether declaring a variable inside a for loop causes it to be created/destroyed at every iteration, there is nothing really to worry about. These variables are not dynamically allocated at runtime, nothing is being malloced here - just some memory is being set aside for use inside the loop. So having the variable inside is just the same as having it outside the loop in terms of performance.
The real difference here is scope not performance. Whether you use a global or local variable only affects where you want this variable to be visible.
In case you're wondering about performance differences: most likely there aren't any. If there are theoretical performance differences, you'll find it hard to actually devise a test to measure them.
A decision like this should not be based on performance but semantics. Unless the semantic behavior of a global variable is required, you should always use automatic (local non-static) variables.
As others have said and surely will say, there are unlikely to be any differences in performance. If there are, the automatic variable will be faster.
The C compiler will have an easier time making optimizations on the variables declared local to the function. The global variable would require an optimizer to perform "Inter-Procedural Data Flow Analysis", which isn't that commonly done.
As an example of the difference, consider that all your declarations initialize the variable to zero. However, in the case of the global variable, the compiler cannot use that information unless it verifies that no flow of control in your program can change the global prior to using it in your example function. In the case of the locally declared ("automatic") variables, there is no way the initial value can be changed by another function (in particular, the compiler verifies that their address is never passed to a sub-function) and the compiler can perform "killed definitions" and "value liveness" analysis to determine whether the zero value can be assumed in some code paths.
Of the two local variables, as a guideline, the optimizer will always have an easier time optimizing access to the variable with the smaller (more limited) scope.
Having stated the above, I would suggest that other answers concerning a bias toward semantics over optimizer-meta-optimization is correct. Use the variable which causes the code to read best, and you will be rewarded with more time returned to you than assisting the def-use optimization calculation.
In general, avoid using a global variable, or any variable which can be accessed more broadly than absolutely necessary. Limited scoping of variables helps prevent bugs from being introduced during later program maintenance.
There are three broad classes of variables: static (global), stack (auto), and register.
Register variables are stored in CPU registers. Registers are very fast word-sized memories, which are integrated in the CPU pipeline. They are free to access, but there are a very limited number of them (typically between 8 and 32 depending on your processor and what operations you're doing).
Stack variables are stored in an area of RAM called the stack. The stack is almost always going to be in the cache, so stack variables typically take 1-4 cycles to access.
Generally, local variables can be either in registers or on the stack. It doesn't matter whether they are allocated at the top of a function or in a loop; they will only be allocated once per function call, and allocation is basically free. The compiler will put variables in registers if at all possible, but if you have more active variables than registers, they won't all fit. Also, if you take the address of a variable, it must be stored on the stack since registers don't have addresses.
Global and static variables are a different beast. Since they are not usually accessed frequently, they may not be in cache, so it could take hundreds of cycles to access them. Also, since the compiler may not know the address of a global variable ahead of time, it may need to be looked up, which is also expensive.
As others have said, don't worry too much about this stuff. It's definitely good to know, but it shouldn't affect the way you write your programs. Write code that makes sense, and let the compiler worry about optimization. If you get into compiler development, then you can start worrying about it. :)
Edit: more details on allocation:
Register variables are allocated by the compiler, so there is no runtime cost. The code will just put a value in a register as soon as the value is produced.
Stack variables are allocated by your program at runtime. Typically, when a function is called, the first thing it will do is reserve enough stack space for all of its local variables. So there is no per-variable cost.
I've been programming with Java for Android quite some while now. Since performance is very important for the stuff I am working on I end up just spamming global variables. I guess everyone will come rushing in now and tell me this is the worst style ever, but lets keep it simple. For Android, local variables means garbage collection and garbage collection is something that kills performance.
Lately I have started using the NDK. Now I feel the urge to actually take all the local variables and change them to global variables. I am wondering though if this makes any sense in c code. Obviously it is no good style, but if it is needed for speed I'll sacrifice the style gladly.
I've looked through older threads about local vs global, but I haven't been able to find anything about speed. So my question is, if I am calling a function very often is it relevant for the speed that local variables are created and die after the function is done? Or doesn't it matter at all and I can happily keep on using the local variables.
I would test it myself, but for some reason the performance of my app goes up and down like a roller coaster and I doubt I'll be able to really make any sense of the data. I hope someone can help me out before I rewrite my whole code for nothing :)
For Android, local variables means garbage collection...
This is an incorrect statement. Local variables are allocated on the stack - not dynamically allocated on the heap.Check out this article on what gets allocated where in Java
As a rule, items allocated on the stack do not require garbage collection/freeing and "die" immediately after the execution leaves its current scope. Stack allocation/deallocation is significantly faster than heap allocation and garbage collection.
Try to avoid global variables for both style and performance reasons. Stack-allocated local variables will perform much faster.
In C, the performance difference depends on the hardware. Loading a global on a RISC processor is more instructions (because you have to load both halves of the address in separate instructions, versus an add to the stack pointer), and then you need to contend with cache issues. For the most part, you can count on your local variables being in the cache. Using globals will thrash the cache a bit and some functions may be very adversely affected.
If you have substantial performance variability while running your app, it is quite likely that your assertion about the performance impact of local variables is immaterial.
The "cost" of creating a local variable in C is zero; it's just bumping a register (the stack pointer) to make space for the local. Then you initialize that variable via whatever means are appropriate. You should be able to know if that is expensive or not by casual inspection. When the function exits, the stack pointer is returned to its previous value, regardless of how many local variables you have.
If your definition of "local variables" is heap allocated objects, though, you will suffer from the cost of memory allocation. Memory allocation is very slow in my opinion, so whatever you can do to get away from malloc/free (and 'new' in Java), the better off you'll be. (I make games, and we tend to use dlmalloc but even that is too slow for regular usage; 400ns per call adds up quick.)
On the MIPS- and ARM-based CPUs found in most Android phones, there is no reason whatsoever to move local variables to global space "for performance." Locals are stored on the stack and a stack allocation is a single op; moreover the entire stack is cleaned up at once on calling ret. Moving them to global space will just make your logic into a snarled mess of indecipherable state for no advantage.
The one place to worry about perf with creating objects is when you are allocating them on the heap (eg with malloc()). This is exactly where C is "more performant than" garbage-collected languages, because you can see and control exactly when these mallocs occur and when they are freed. It is not really the case that C malloc() is any faster than Java new; rather, because every allocation is transparent and explicit to you, you can do the necessary work to make sure that such slow operations happen as little as possible.
By the way, declaring a variable static within a C function will give you the behavior of a global without littering the global namespace.
But as mentioned, declaring automatic variables on the stack takes 0 time and accessing those variables is also extremely quick, so there is not much reason to avoid function local variables.
If you really need this extreme level of optimization you should look to inline all your commonly called functions to avoid the call overhead.