Recursion in C, efficiency vs. elegance

Question

From what I have been told, recursive functions are much loved in C programming due to their "elegance" and the compactness of their code, and because they can be easier to understand than their iterative equivalents.
On the other hand, recursive functions are spectacularly inefficient in C. They use more memory with each recursion, and the context switching due to calling the function over and over again also slows things down. This seems to me like it's mostly a losing proposition.
There is the readability/maintainability perspective... But C conventions already encourage terseness and efficiency over readability (at least if the K&R text is anything to judge by). If your code is already compact and mostly inscrutable, what's the point of making it a little more readable at the cost of completely destroying its performance? Is there something here I'm not understanding?

Answer 1

Grinch wrote:A smart solution bringing better efficiency is a solution which solves it's problem faster, thus using fewer clockcycles. What do you think profiling your code is about?
This thread is discussing whether we should structure code so that is efficient or maintainable. I'm stating that the biggest gains come from how you solve the problem, only in a few cases it is necessary to optimise small sections at the expense of clarity. 99% for maintenance, 1% for efficiency. I enjoy profiling, it is interesting to discover what is taking the time and consider ways of improving this.
Grinch wrote:I don't know what 'tranced' means, and also what does 'tuned to perfection' mean in this context if it does not involve using a 'better algorithm'???
Tranced -> easily out performed. Once the optimum algorithm is being used, other improvements are marginal. Yes, code written badly may have a large effect.
Grinch wrote:There are certainly areas in programs where there's absolutely no point spending time optimizing, like parts which are called very seldom, obviously you will focus your optimization on areas which are heavily used during the programs execution, again profiling allows you to easily pinpoint these areas.
In complete agreement - this will be the majority of the code in a reasonably sized application.
Grinch wrote:
I don't see this happening, dividing functions into smaller segments helps in organizing the code more efficiently but really the compiler register allocator should not have any particular problem with optimizing a larger function than several small ones, unless I'm mistaking what you wrote here. For each call there's also the overhead of potential cache misses, stack management etc, there's a reason there's an 'inline' keyword (although compiler heuristics have become better at automatically determining when to inline, particularly when the function is defined as 'static' or the compiler is using link-time-optimization which allows it to optimize the program as a whole entity rather than on a file-by-file basis).
You said there have been experiments, can you point me to these?
There is a limited number of registers and local proximity of data/jumps results in efficiency gains. The trainers of a functional programming course specifically performed this experiment to show that breaking large sequential blocks into functions actually improves performance.
Grinch wrote:Optimized code does not equal non-maintainability, I'm not sure what you mean by 'flexibility' but certainly in performance terms it's most often so that a special solution particularly tailored for the problem at hand will beat a generic solution, often by a wide margin depending on just how optimized the 'special solution' is and of course what the problem is and what possibilities for optimization it offers.
Also agree with you on this point. Flexibility - this is where the same code can be easily reused without modification to perform a similar task. When software is configured, tested and scrutinised, it is better if this does not have to be updated - see factory or decorator patterns etc.