Not generally. In both cases, the function call machine instruction
needs the address of function. Loading a register with
the function pointer (if it is not already available,
for example as an offset from already loaded base register)
may or may not add to the instruction count; depending
on what relative branch size(s) the function call instruction
supports even a direct call may require the compiler to
load a function pointer into a register anyway.
In your example, it depends on how the compiler implements
the switch statement - it could indeed just index into
a four element array containing the function pointers
when compiled with the appropriate optimization flags.
For a good while I've been wanting to use function pointers
& I finally found an opportunity to do so...
Currently I have:
switch(ops.export) {
case 1: outputTXT(p, nodes, c); break;
case 2: outputCSV(p, nodes, c); break;
case 3: outputSQL(p, nodes, c); break;
case 4: outputHTM(p, nodes, c); break;
}
But instead I could use:
void (*output[])(FILE*, BLOCK[], int) =
{ outputTXT, outputCSV, outputSQL, outputHTM };
// do stuff
output[ops.export -1](p, nodes, c);
Now here's where I'm unsure: Perhaps the overhead of an indirect call
is miniscule, even negligible. But there *IS* additional overhead when
using function pointers correct?
For a good while I've been wanting to use function pointers
& I finally found an opportunity to do so...
Currently I have:
switch(ops.export) {
case 1: outputTXT(p, nodes, c); break;
case 2: outputCSV(p, nodes, c); break;
case 3: outputSQL(p, nodes, c); break;
case 4: outputHTM(p, nodes, c); break;
}
But instead I could use:
void (*output[])(FILE*, BLOCK[], int) =
{ outputTXT, outputCSV, outputSQL, outputHTM };
// do stuff
output[ops.export -1](p, nodes, c);
Now here's where I'm unsure: Perhaps the overhead of an indirect call
is miniscule, even negligible. But there *IS* additional overhead when
using function pointers correct?
But judging from the names of your functions, each one looks to be
writing stuff out to a file. Then the function call overhead will be insignificant.
Note that switch will also check that the ops.export index is in the
correct range; if less than 1 or greater than 4, nothing is called, but
the function table version will go wrong.
BTW you seem to have mixed up 1-based and 0-based here: 1 means TXT in
the switch version, but CSV in the function pointer version since arrays
are 0-based.
Now here's where I'm unsure: Perhaps the overhead of an indirect call is miniscule, even negligible. But there *IS* additional overhead when
using function pointers correct?
ops.export is always 1 to 4, so:
output[ops.export -1](p, nodes, c);
keeps it within bounds of zero indexing (neverteless, good catch).
Scott Lurndal <scott@slp53.sl.home> wrote:
Not generally. In both cases, the function call machine instruction
needs the address of function. Loading a register with
the function pointer (if it is not already available,
for example as an offset from already loaded base register)
may or may not add to the instruction count; depending
on what relative branch size(s) the function call instruction
supports even a direct call may require the compiler to
load a function pointer into a register anyway.
In your example, it depends on how the compiler implements
the switch statement - it could indeed just index into
a four element array containing the function pointers
when compiled with the appropriate optimization flags.
Thanks Scott.
I keep reading otherwise (comfused about it all really):
Compilers will often inline a direct call and perform aggressive
holistic optimsation of the resulting subroutine whilst they won't do so
with an indirect call, even if the value is passed as a constant. But of course it depends on the compiler. Whether a direct call is in itself
faster than an indirect call or not depends on the architecture. Many architectures don't really support direct calls and they are faked up by loading a constant into a register, and so there is no difference in execution speed. But sometimes the indirect call is a separate
instruction and so there can be a minuscule overhead.
The only place where function pointers (which generalize
to functions in this context) have a performance impact
is when using indirection into a shared object via a procedure
linkage table. That overhead is independent upon weather
you use a function or a function pointer.
You example would only be affected by that performance
impact if the function being called were in a different
shared object or dynamically linked library.
???Premature optimization is the root of all evil.???
-- variously attributed to Tony Hoare or Donald Knuth
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
“Premature optimization is the root of all evil.”
-- variously attributed to Tony Hoare or Donald Knuth
Aye, that's what I want to avoid, cute/crafty code might cause issues...
For a good while I've been wanting to use function pointers
& I finally found an opportunity to do so...
Currently I have:
switch(ops.export) {
case 1: outputTXT(p, nodes, c); break;
case 2: outputCSV(p, nodes, c); break;
case 3: outputSQL(p, nodes, c); break;
case 4: outputHTM(p, nodes, c); break;
}
But instead I could use:
void (*output[])(FILE*, BLOCK[], int) =
{ outputTXT, outputCSV, outputSQL, outputHTM };
// do stuff
output[ops.export -1](p, nodes, c);
Now here's where I'm unsure: Perhaps the overhead of an indirect
call is miniscule, even negligible. But there *IS* additional
overhead when using function pointers correct?
Let me give the conclusion first and the explanation second.
Conclusion: if you think the array-of-function-pointers approach
looks better or improves program structure then by all means use
it.
Explanation: I got interested in this question some years ago,
in a similar scenario. Calling through a pointer-to-function can
and sometimes does incur a performance penalty compared to
calling a function directly. What I was interested in though is
a comparison like the one you are interested in: should I use
a switch() with direct calls, or indirect calls using an array of
function pointers. So I did some measurements. The results were
very nearly the same for the two different schemes. Choosing one
approach over the other was a wash, performance-wise. I didn't
do an exhaustive study or anything like that, but the results I
did get showed that, at least to first order, there is no speed
preference for either choice. So pick the one that gives a more
nicely structured program, and don't worry about which one might
be faster.
(Later on you might want to do some measurements and actually see
which approach runs faster, but the evidence suggests there is no
reason to worry about that now.)
On 18/02/2024 11:26, Mike Sanders wrote:
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:If you are writing a bytecode interpeter often there is a big switch in
Let me give the conclusion first and the explanation second.
Conclusion: if you think the array-of-function-pointers approach
looks better or improves program structure then by all means use
it.
Explanation: I got interested in this question some years ago,
in a similar scenario. Calling through a pointer-to-function can
and sometimes does incur a performance penalty compared to
calling a function directly. What I was interested in though is
a comparison like the one you are interested in: should I use
a switch() with direct calls, or indirect calls using an array of
function pointers. So I did some measurements. The results were
very nearly the same for the two different schemes. Choosing one
approach over the other was a wash, performance-wise. I didn't
do an exhaustive study or anything like that, but the results I
did get showed that, at least to first order, there is no speed
preference for either choice. So pick the one that gives a more
nicely structured program, and don't worry about which one might
be faster.
(Later on you might want to do some measurements and actually see
which approach runs faster, but the evidence suggests there is no
reason to worry about that now.)
Excellent reply Tim, its right where I'm at. And my love/hate
relationship with C continues =)
the innermost loop, and so it is very important to optimise it.
For a good while I've been wanting to use function pointers
& I finally found an opportunity to do so...
Currently I have:
switch(ops.export) {
case 1: outputTXT(p, nodes, c); break;
case 2: outputCSV(p, nodes, c); break;
case 3: outputSQL(p, nodes, c); break;
case 4: outputHTM(p, nodes, c); break;
}
But instead I could use:
void (*output[])(FILE*, BLOCK[], int) =
{ outputTXT, outputCSV, outputSQL, outputHTM };
// do stuff
output[ops.export -1](p, nodes, c);
Now here's where I'm unsure: Perhaps the overhead of an indirect call
is miniscule, even negligible. But there *IS* additional overhead when
using function pointers correct?
On 17/02/2024 22:16, Mike Sanders wrote:
For a good while I've been wanting to use function pointers
& I finally found an opportunity to do so...
Currently I have:
switch(ops.export) {
case 1: outputTXT(p, nodes, c); break;
case 2: outputCSV(p, nodes, c); break;
case 3: outputSQL(p, nodes, c); break;
case 4: outputHTM(p, nodes, c); break;
}
But instead I could use:
void (*output[])(FILE*, BLOCK[], int) =
{ outputTXT, outputCSV, outputSQL, outputHTM };
// do stuff
output[ops.export -1](p, nodes, c);
Now here's where I'm unsure: Perhaps the overhead of an indirect call
is miniscule, even negligible. But there *IS* additional overhead when
using function pointers correct?
First off, only concern yourself about the overhead if the overhead is relevant - not all code has to be at top efficiency. But all code
benefits from being written in a clear and maintainable manner, with
minimal risk of errors. So keep that in mind when making such design decisions.
I personally would not use function pointers here. You can have
different balances and opinions, and the rest of your code can influence things, but I will list my justifications here.
1. You can get function pointers wrong. You can, of course, get all
kinds of things wrong - but when a function pointer goes wrong, it can
be extremely difficult to figure out what is happening and debug the code.
2. Switches have range-checking built in, array lookups here do not.
3. Switches can work directly with enumerated types which are almost certainly a much better choice here for the type of "ops.export". Drop
the "magic numbers" and use names from an enumerated type. This makes
the switch clearer, and easier to maintain. It lets you use "-Wswitch-enums" in gcc/clang to warn if the switch does not handle all
the cases.
4. Your ordering in the switch can be whatever suits your preferences
and for maintenance, not the numerical ordering needed for array initialisation.
5. Now that you have an order free from numbers, there are no
complications or risks if you want to remove one of the actions.
6. The actions are run from within the switch, not via pointers. That
means the compiler can optimise far better, and - often more importantly
- can do more static analysis to find potential problems at compile
time. It also means you don't have to squeeze everything into one set
of parameters - different actions can have different parameters.
7. Tools that deal with call tracing work much better with the switch version. That includes tools to check stack depth (rarely important on PC's, but useful in small embedded systems), code coverage,
documentation, etc., can do a better job. If you are debugging and need
to work backwards to find how you got to a particular point in the
program, it is vastly easier if there are no function pointers in the way.
There are certainly situations where function pointers make code better
- in particular, using callbacks avoids dependencies between different
parts of the code. But for my own use, I rarely find them the best choice.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 32:15:05 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,115 |