Greg Stark <gsst...@mit.edu> writes: > On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> But it might be a good change anyway from a performance standpoint, >> in case a call through a function pointer is faster than a big switch. >> Have you tried benchmarking it on common platforms?
> I've always wondered why we didn't use function pointers. It seems > like it would make the code a lot easier to maintain with fewer places > that need to be updated every time we add a node. > But I always assumed a big part of the reason was performance. > Generally compilers hate optimizing code using function pointers. They > pretty much kill any inter-procedural optimization since it's very > hard to figure out what set of functions you might have called and > make any deductions about what side effects those functions might or > might not have had. Even at the chip level function pointers tend to > be slow since they cause full pipeline stalls where the processor has > no idea where the next instruction is coming from until it's finished > loading the data from the previous instruction. At least in the case of the plan-node-related switches, the called functions tend to be big and ugly enough that it's really hard to credit any meaningful inter-procedural optimization could happen. Side effects would have to be "pretty much everything". > On the other hand of course it's not obvious what algorithm gcc should > use to implement largish switch statements like these. It might be > doing a fairly large number of operations doing a binary search or > hash lookup to determine which branch to take. I confess to not having actually examined the assembly code anytime recently, but I'd always supposed it would be an array-lookup anytime the set of case labels was reasonably dense, which it should be in these cases. So I'm not sure I believe the pipeline stall argument either. Any way you slice it, there's going to be a call to a function that is going to be really really hard to predict in advance --- unless of course you rely on statistics like "where did I jump to the last few times I was here", which I think modern CPUs do have the ability to do. But this is all just arm-waving of course. Benchmarks would be a lot more convincing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers