📄 mefficc.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC-html40/frameset.dtd">
<HTML>
<HEAD>
<TITLE>More Effective C++ | Efficiency</TITLE>
<LINK REL=STYLESHEET HREF=../INTRO/ECMEC.CSS>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/COOKIE.JS"></SCRIPT>
<SCRIPT LANGUAGE="Javascript">var imagemax = 0; setCurrentMax(0);</SCRIPT>
<SCRIPT LANGUAGE="Javascript" SRC="../JAVA/DINGBATS.JS"></SCRIPT>
<SCRIPT>
var dingbase = "MEFFICDR.HTM";
var dingtext = "MEC++ Efficiency, P";
if (self == top) {
top.location.replace(dingbase + this.location.hash);
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" ONLOAD="setResize()">
<!-- SectionName="MEC++ Chapter Intro: Efficiency" -->
<A NAME="66196"></A>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./MI15_FR.HTM" TARGET="_top">Item 15:Understand the costs of exception handling</A> <BR> Continue to <A HREF="./MI16_FR.HTM" TARGET="_top">Item 16: Remember the 80-20 rule</A></FONT></DIV>
<A NAME="71807"> </A><A NAME="P81"></A>
<P><A NAME="dingp1"></A><font ID="mgtitle">Efficiency</font><SCRIPT>create_link(1);</SCRIPT>
</P>
<A NAME="71809"> </A>
<P><A NAME="dingp2"></A>
I harbor a suspicion that someone has performed secret <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>°</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=pavlov" onMouseOver="self.status='Pavlovian Experiments Home Page'; return true" onMouseOut="self.status=self.defaultStatus" target="_top">Pavlovian</NOBR> experiments</A> on C++ software developers. How else can one explain the fact that when the word "efficiency" is mentioned, scores of programmers start to <NOBR>drool?<SCRIPT>create_link(2);</SCRIPT>
</NOBR></P><A NAME="49941"> </A>
<P><A NAME="dingp3"></A>
In fact, efficiency is no laughing matter. Programs that are too big or too slow fail to find acceptance, no matter how compelling their merits. This is perhaps as it should be. Software is supposed to help us do things better, and it's difficult to argue that slower is better, that demanding 32 megabytes of memory is better than requiring a mere 16, that chewing up 100 megabytes of disk space is better than swallowing only 50. Furthermore, though some programs take longer and use more memory because they perform more ambitious computations, too many programs can blame their sorry pace and bloated footprint on nothing more than bad design and slipshod <NOBR>programming.<SCRIPT>create_link(3);</SCRIPT>
</NOBR></P><A NAME="49923"> </A>
<P><A NAME="dingp4"></A>
Writing efficient programs in C++ starts with the recognition that C++ may well have nothing to do with any performance problems you've been having. If you want to write an efficient C++ program, you must first be able to write an efficient <I>program</I>. Too many developers overlook this simple truth. Yes, loops may be unrolled by hand and multiplications may be replaced by shift operations, but such micro-tuning leads nowhere if the higher-level algorithms you employ are inherently inefficient. Do you use quadratic algorithms when linear ones are available? Do you compute the same value over and over? Do you squander opportunities to reduce the average cost of expensive operations? If so, you can hardly be surprised if your programs are described like second-rate tourist attractions: worth a look, but only if you've got some extra <NOBR>time.<SCRIPT>create_link(4);</SCRIPT>
</NOBR></P><A NAME="50003"> </A>
<P><A NAME="dingp5"></A>
The material in this chapter attacks the topic of efficiency from two angles. The first is language-independent, focusing on things you can do in any programming language. C++ provides a particularly appealing <A NAME="P82"></A>implementation medium for these ideas, because its strong support for encapsulation makes it possible to replace inefficient class implementations with better algorithms and data structures that support the same <NOBR>interface.<SCRIPT>create_link(5);</SCRIPT>
</NOBR></P><A NAME="50028"> </A>
<P><A NAME="dingp6"></A>
The second focus is on C++ itself. High-performance algorithms and data structures are great, but sloppy implementation practices can reduce their effectiveness considerably. The most insidious mistake is both simple to make and hard to recognize: creating and destroying too many objects. Superfluous object constructions and destructions act like a hemorrhage on your program's performance, with precious clock-ticks bleeding away each time an unnecessary object is created and destroyed. This problem is so pervasive in C++ programs, I devote four separate items to describing where these objects come from and how you can eliminate them without compromising the correctness of your <NOBR>code.<SCRIPT>create_link(6);</SCRIPT>
</NOBR></P><A NAME="50050"> </A>
<P><A NAME="dingp7"></A>
Programs don't get big and slow only by creating too many objects. Other potholes on the road to high performance include library selection and implementations of language features. In the items that follow, I address these issues, <NOBR>too.<SCRIPT>create_link(7);</SCRIPT>
</NOBR></P><A NAME="64580"> </A>
<P><A NAME="dingp8"></A>
After reading the material in this chapter, you'll be familiar with several principles that can improve the performance of virtually any program you write, you'll know exactly how to prevent unnecessary objects from creeping into your software, and you'll have a keener awareness of how your compilers behave when generating <NOBR>executables.<SCRIPT>create_link(8);</SCRIPT>
</NOBR></P><A NAME="64646"> </A>
<P><A NAME="dingp9"></A>
It's been said that forewarned is forearmed. If so, think of the information that follows as preparation for <NOBR>battle.<SCRIPT>create_link(9);</SCRIPT>
</NOBR></p>
<DIV ALIGN="CENTER"><FONT SIZE="-1">Back to <A HREF="./MI15_FR.HTM" TARGET="_top">Item 15: Understand the costs of exception handling</A> <BR> Continue to <A HREF="./MI16_FR.HTM" TARGET="_top">Item 16: Remember the 80-20 rule</A></FONT></DIV>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -