understanding of some performance principles,as well as informationonC+performance traps and pitfalls The 80-20 rule is an important principle in the world of software construction.We adopt it in the writing of this book as well:20%of all performance bugs will show up%of the time.We therefore chose to d unts the mo This h in those perte ues tha 、i set of all r ssible performance bus and their solutions:hence we will not cover what we consider esoteric and rare performance pitfalls. oubtedly biased b of server-side The profile of performance problem.Generic performance principles transcend distinct domains,and apply equally well in omains oth than networ ting software We do not delve into the asymptotic complexity of algorithms,data structures and the latest anc focus on simple.p ractical evervday coding and design principles that vield large performance improvements We point out common de sign and cod ing prac ces that l of sube(and not so subtle)performance principles So how do we parate myth from reality?Is C+ performance truly inferior to that of C?It is our pears to be the same thing the Cp oganeneal aster.How er,we also claim that the apparent similarity of the two programs typically is based on thei tion is that the speed cfcouad hjust acpbeperfomnce,but yidsareprfomanc We w ould like to thank .The toughest part was getting Julia Sime made a si ificant contribution to the early the one who pointed out to u rence our opinions ough t they ares Many thanks to the reviewers hired by Addison-Wesley,their feedback was extremely valuable. Heather Kreger Kath n Britton ruth willenborg David wisler Bala raiaraman Don "Spike' Washburn,and Nils Brubaker. Last but not least,we would like to thank our wives,Cynthia Powers Bulka and Ruth Washington Mayhewvii understanding of some performance principles, as well as information on C++ performance traps and pitfalls. The 80-20 rule is an important principle in the world of software construction. We adopt it in the writing of this book as well: 20% of all performance bugs will show up 80% of the time. We therefore chose to concentrate our efforts where it counts the most. We are interested in those performance issues that arise frequently in industrial code and have significant impact. This book is not an exhaustive discussion of the set of all possible performance bugs and their solutions; hence, we will not cover what we consider esoteric and rare performance pitfalls. Our point of view is undoubtedly biased by our practical experience as programmers of server-side, performance-critical communications software. This bias impacts the book in several ways: • The profile of performance issues that we encounter in practice may be slightly different in nature than those found in scientific computing, database applications, and other domains. That’s not a problem. Generic performance principles transcend distinct domains, and apply equally well in domains other than networking software. • At times, we invented contrived examples to drive a point home, although we tried to minimize this. We have made enough coding mistakes in the past to have a sizable collection of samples taken from real production-level code that we have worked on. Our expertise was earned the hard way—by learning from our own mistakes as well as those of our colleagues. As much as possible, we illustrated our points with real code samples. • We do not delve into the asymptotic complexity of algorithms, data structures, and the latest and greatest techniques for accessing, sorting, searching, and compressing data. These are important topics, but they have been extensively covered elsewhere [Knu73, BR95, KP74]. Instead, we focus on simple, practical, everyday coding and design principles that yield large performance improvements. We point out common design and coding practices that lead to poor performance, whether it be through the unwitting use of language features that carry high hidden costs or through violating any number of subtle (and not so subtle) performance principles. So how do we separate myth from reality? Is C++ performance truly inferior to that of C? It is our contention that the common perception of inferior C++ performance is invalid. We concede that in general, when comparing a C program to a C++ version of what appears to be the same thing, the C program is generally faster. However, we also claim that the apparent similarity of the two programs typically is based on their data handling functionality, not their correctness, robustness, or ease of maintenance. Our contention is that when C programs are brought up to the level of C++ programs in these regards, the speed differences disappear, or the C++ versions are faster. Thus C++ is inherently neither slower nor faster. It could be either, depending on how it is used and what is required from it. It’s the way it is used that matters: If used properly, C++ can yield software systems exhibiting not just acceptable performance, but yield superior software performance. We would like to thank the many people who contributed to this work. The toughest part was getting started and it was our editor, Marina Lang, who was instrumental in getting this project off the ground. Julia Sime made a significant contribution to the early draft and Yomtov Meged contributed many valuable suggestions as well. He also was the one who pointed out to us the subtle difference between our opinions and the absolute truth. Although those two notions may coincide at times, they are still distinct. Many thanks to the reviewers hired by Addison-Wesley; their feedback was extremely valuable. Thanks also to our friends and colleagues who reviewed portions of the manuscript. They are, in no particular order, Cyndy Ross, Art Francis, Scott Snyder, Tricia York, Michael Fraenkel, Carol Jones, Heather Kreger, Kathryn Britton, Ruth Willenborg, David Wisler, Bala Rajaraman, Don “Spike” Washburn, and Nils Brubaker. Last but not least, we would like to thank our wives, Cynthia Powers Bulka and Ruth Washington Mayhew