This much less about overhead than scope. If can declare the variable as global, but then any function can see the variable and it will not die until the program dies. This might seem better, but then if the variable is in use by one function, you can't call other function that also wants to use that variable without discarding the value and corrupting the data of the other function.
If you declare a variable in the function, then it's local to function only and can't be accessed by any other function. This is considered the better way and more secure.
If you're worried about it, try compiling the program both ways and timing it to see which is faster. But I think most modern compilers take this into account when building the symbol table. You might find they preallocate space for variables they determine will see a lot of use.
The only difference is the declaration of my variable. Since myfunction() will be called many times will it add an additional overhead if it will create mybuffer over and over?
Local variables are allocated on the stack, global variables are allocated on the heap. Allocating on the stack is (almost) always much faster than the heap as it's basically just one instruction to move the stack pointer.
But unless you are calling this function more than anything else in your code, you probably don't have to worry about performance as a consideration for where you allocate your variables. You can instead worry about security and bugs, in which case you should follow best practices and (almost) never use a global variable unless you have an explicit need to do so. Keep your variables to the most restricted scope you need and you'll save yourself a lot of headache.
This is good programming about declaration variable. Declare your variables near the beginning of your program, just after the line with the initial curly bracket. Cluster them all up right there. Each variable needs an identifier that distinguishes it from the others.