RE: Compiling C++ modules

["David Schwartz" <davids@webmaster.com>]

> > The cost in developer time is borne once. The cost of performance
> > is borne every time you run the application.

> The cost in developer time is borne every time someone needs to
> modify the code.

	Or understand the code. Or debug the code. Or verify that the code operates
correctly. Or reuse the code for another purpose.

	In the bad old days, performance was the number one priority because
computers were slow and resources were scarce -- if you didn't your code
wasn't usable. There is still a small amount of code where performance is
truly the most important priority. Certainly, very low-level kernel code
falls in this category.

	We aren't in the bad old days anymore. And there are quite a few things
that are important other than performance. Clear, simple code is easier to
understand and maintain and more likely to be correct. Modifications are
less likely to break hidden dependencies. Code that isn't heavily optimized
is more likely to be secure.

	And the supreme irony is that the code often performs better anyway! There
are a lot of reasons why this is often the case. For example, clearer more
modular code is easier to optimize algorithmically. Hand optimizations may
remain in code long past the point where they made sense and to the point
where they become pessimizations because of new CPU architectures or smarter
compilers. Poor code organization mixes performance-critical code with code
that's not performance-critical so that the critical code is harder to
identify and optimize.

	I am not saying that the use of C++ over C is likely to improve
performance. I'm saying that there's a lot of code where performance is not
the most important priority, and that this type of code accounts for the
majority of code in a monolithic kernel.

	DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/