Item M23: Consider changing the library
The design of library is a compromise process.
the ideal library should be short, fast, powerful, flexible, extensible, intuitive, universally applicable, with good support, no use of constraints, no errors. This also does not exist. Libraries that are optimized for size and speed are generally not portable. Libraries with a lot of functionality are not intuitive. Libraries with no errors are limited in scope. In the real world, you can't have every thing, you have to pay.
Different designers assign different priorities to these conditions. They sacrificed different things in the design. As a result, two libraries that provide the same functionality have completely different performance characteristics.
For example, consider the iostream and stdio libraries, both of which are available to C + + programmers. The iostream library has several advantages over the stdio in C (see effective C + +). For example it is
type safety(Type-safe), it is
can be extendedOf
However, in terms of efficiency, the iostream library is always inferior to stdio because the stdio produces an execution file that is smaller and executes faster than the execution file produced by iostream.
First consider the problem of execution speed. One way to master the performance difference between iostream and Stdio is to run it with these two libraries
Benchmark Program。 But you have to remember that benchmark can also lie. Not only is it difficult to come up with a set of data that represents a typical use of a program or library, but it is useless to take it out, unless there is a reliable way to judge that you or your client are typical representatives. But benchmark can still provide some information on the comparison between different solutions to the same problem, so although it is foolish to rely entirely on benchmark, it is foolish to ignore them.
Let's test a simple benchmark program that only tests the most basic I/O functions. The program reads 30,000 floating-point numbers from the standard input and writes them in a fixed format to the standard output. The compile-time preprocessing symbol stdio determines whether to use Stdio or iostream. If this symbol is defined, it is used stdio, otherwise the iostream library is used.
#ifdef stdio#include <stdio.h> #else # include <iostream> #include <iomanip>using namespace std;# endifconst int VALUES = 30000; # of values to Read/write int main () { double D; for (int n = 1; n <= VALUES; ++n) {#ifdef STDIO scanf ("%lf", &d); printf ("%10.5f", d); #else cin >> D; cout << SETW (Ten) //Set field width << setprecision (5) //Set decimal position << setiosflags ( Ios::showpoint) //keep trailing 0s << setiosflags (ios::fixed) //Use these settings << D; #endif if (n% 5 = = 0) {#ifdef STDIO printf ("\ n"); #else cout << ' \ n '; #endif } } return 0;
When the natural logarithm of a positive integer is passed to the program, it outputs:
0.00000 0.69315 1.09861 1.38629 1.609441.79176 1.94591 2.07944 2.19722 2.302592.39790 2.48491 2.56495 2.63906 2.708052.77259 2.83321 2.89037 2.94444 2.995733.04452 3.09104 3.13549 3.17805 3.21888
This output indicates that the use of iostreams can also produce fixed-format I/O. Of course
cout << SETW (Ten) << setprecision (5) << setiosflags (ios::showpoint) << Setiosflags (ios::fixed) << D;
Far less than printf ("%10.5f", D); Easy to enter. But the operator << is both type safe (type-safe) and extensible, while printf does not have both of these advantages.
I have made several different combinations of computers, operating systems, and compilers, running this program on it, in each case using stdio programs to run faster. Advantage it's just a bit faster (about 20%) and sometimes a lot faster (nearly 200%), but I've never met a iostream implementation that runs as fast as the corresponding stdio. In addition, the size of the program using Stdio is smaller (and sometimes much smaller) than the corresponding program using iostream. (This difference is negligible for the size of the program in reality).
It should be noted that the efficiency of stdio is largely determined by its code implementation,So the system I've tested for future implementations or the current implementations of systems I haven't tested may show no significant difference between iostream and stdio.
In fact, there are reasons to believe that a iostream code implementation is faster than stdio because iostream determines the type of their operands at compile time, while the Stdio function parses the format string at run time. The performance contrast between iostream and Stdio is just an example, it's not important, it's important that different libraries with the same functionality take different tradeoffs on performance, so once you find the bottleneck in the software (by making a profile see article M16),
you should know if it is possible to remove the bottleneck by replacing the library。 For example, if your program has an I/O bottleneck, you might consider replacing iostream with stdio, and if the program is using a lot of time to dynamically allocate and release memory, you can think about whether there are other operator new and operator The implementation of the delete is available (see Terms M8 and effective C + + clause 10).
because different libraries contain different design concepts in terms of efficiency, scalability, portability, type safety, and other areas, you can sometimes dramatically increase the efficiency of your software by transforming the library that gives you more performance considerations.
More effective C + +----(23) Consider changing the library
