In principle, there's only one copy of the code, whether it's static member functions or not:

• In C++ you can easily verify this by looking at the assembler list of the generated code.
• I'm not Java expert, but from the JNI specification you can deduce it's the same logic: you can fetch a single reference to a function and call it many times for different objects (passing it a class reference as argument, as well as the object reference if it's not a static method).

Using a static or a non-static function will hence not change the memory footprint.

There is in reality a very very small difference, both in the code generated as well as in the memory consumed on the stack during the execution time of the function:

• A call to the non-static function requires to pass a reference/pointer to the object on which the function/method is applied. This requires usually an additional push and a pop instructions in the calling sequence.
• A call to a static function doesn't require this overhead.

But this is truely neglectible: we are speaking of one or two machine instructions more or less compared to the full code. So it's definitively not something to worry about.

The stack consumption difference at run-time is limited to the time of the execution of the function, to the size of a pointer. THis is also neglectible, unless you are thinking of a a function called recursively a huge number of times (several millions of time).

So in conclusion, I fully share gnasher729 opinion: premature optimization is the root of all evil. If the function is independent of the objet make it static and that should be the only criteria.

In principle, there's only one copy of the code, whether it's static member functions or not:

• In C++ you can easily verify this by looking at the assembler list of the generated code.
• I'm not Java expert, but from the JNI specification you can deduce it's the same logic: you can fetch a single reference to a function and call it many times for different objects (passing it a class reference as argument, as well as the object reference if it's not a static method).

Using a static or a non-static function will hence not change the memory footprint.

There is in reality a very very small difference, both in the code generated as well as in the memory consumed on the stack during the execution time of the function:

• A call to the non-static function requires to pass a reference/pointer to the object on which the function/method is applied. This requires usually an additional push and a pop instructions in the calling sequence.
• A call to a static function doesn't require this overhead.

But this is truly negligible: we are speaking of one or two machine instructions more or less compared to the full code. So it's definitively not something to worry about.

The stack consumption difference at run-time is limited to the time of the execution of the function, to the size of a pointer. This is also negligible, unless you are thinking of a a function called recursively a huge number of times (several millions of time).

So in conclusion, I fully share gnasher729 opinion: premature optimization is the root of all evil. If the function is independent of the object make it static and that should be the only criteria.