C++软件优化全攻略：Windows/Linux/DNC平台详解

线程

需积分: 9 44 浏览量更新于2024-07-16 收藏 1.79MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

有多种方法可以替代分析器。一个简单的替代方法是在调试器中运行程序，并在程序运行时按下break。如果有一个热点，

占用 90%的 CPU 时间，那么中断有 90%的机会发生在这个热点。重复中断几次可能足以确定一个热点。在调试器中使用调

用堆栈来识别热点周围的情况。

有时，识别性能瓶颈的最佳方法是将度量工具直接放入代码中，而不是使用现成的分析器。这虽然不能解决与概要分析相关

的所有问题，但通常会提供更可靠的结果。如果你不满意分析器的工作方式，那么你可以将所需的测量仪器插入程序本身。

你可以添加计数器变量来计算程序的每个部分执行了多少次。此外，你可以读取程序中每个最重要或关键部分前后的时间，

以度量每个部分所花费的时间。有关此方法的进一步讨论，请参阅 16 测试速度。

你的测量代码应该包含 #if 指令，以便可以在代码的最终版本中禁用它。在代码中插入自己的分析工具，是在程序开发过程

中跟踪程序性能的一种非常有用的方法。

如果时间间隔很短，时间测量可能需要很高的分辨率。在 Windows 中，你可以使用 GetTickCount 或 QueryPerformance

Counter 函数获得毫秒级的分辨率。使用 CPU 中的时间戳计数器可以获得更高的分辨率，它以 CPU 时钟频率计数（在

Windows 中： __rdtsc()）。

如果线程在不同的 CPU 内核之间跳转，时间戳计数器将会失效。在时间度量期间，你可能必须将线程固定到特定的CPU核

心，以避免这种情况。（在Windows 中是SetThreadAffinityMask，在Linux 中是sched_setaffness﴿。

程序应该用一组真实的测试数据进行测试。测试数据应该具有典型的随机性，以便获得真实数量的缓存丢失和分支错误预测

的情况。

当发现程序中最耗时的部分时，重要的是将优化工作集中在耗时的部分上。关键代码片段可以使用16 测试速度中描述的方

法进行进一步测试和研究。

分析器对查找出与 CPU 密集型代码相关的问题最有帮助。但是许多程序在加载文件或访问数据库、网络和其他资源时所花

费的时间比算术运算要多。下面几节将讨论程序中最常见的耗时部分。

3.3 安装程序

安装程序包所需的时间通常不被认为是软件优化问题。但这肯定会占用用户的时间。如果软件优化的目标是为了用户节省时

间，那么安装软件包并使其正常工作所花费的时间是不能忽略的。由于现代软件的高度复杂性，安装过程花费一个多小时是

很正常的。为了找到并解决兼容性问题，用户必须多次重新安装软件包，这种情况也很常见。

软件开发人员在决定软件包是否使用需要安装许多文件的复杂框架时，应该考虑安装时间和兼容性问题。安装过程应该始终

使用标准化的安装工具。需要可以在开始时选择所有安装的选项，以便在无人参与的情况下继续安装过程的其余部分。卸载

也应该以标准化的方式进行

3.4 自动更新

许多软件程序通过互联网定期自动下载更新。有些程序在每次计算机启动时都会搜索更新，即使该程序从未被使用过。安装

了许多这类程序的计算机需要花费几分钟才能启动，这完全是在浪费用户的时间。其他一些程序在每次启动时搜索更新。如

果当前版本满足用户的需求，则用户可能不需要更新。搜索更新应该是可选的，应该默认是关闭的，除非有令人信服的安全

理由进行更新。更新过程应该在低优先级线程中运行，并且只有在程序实际使用时才运行。任何程序在不使用时，都不应该

在后台进程中运行。下载的程序更新的安装应该延迟到程序关闭并重新启动。

操作系统的更新尤其耗时。有时安装操作系统的自动更新需要几个小时。这是非常有问题的，因为这些耗时的更新可能在不

方便的时候出现。如果用户在离开工作场所之前出于安全原因必须关闭或注销计算机，并且系统禁止用户在更新过程中关闭

计算机，那么这将是一个非常大的问题。

3.5 程序加载

很多时候，加载一个程序要比执行它花费更多的时间。对于基于大型运行时框架、中间代码、解释器、即时编译器等的程

序，加载时间可能会非常长，这是使用Java, C#， Visual Basic 等编程语言编写的程序的常见情况。

但是，即使是用编译的C++ 实现的程序，加载程序也会耗费时间。如果程序使用大量运行时 DLL（动态链接的库或共享对

象）、资源文件、配置文件、帮助文件和数据库，通常会发生这种情况。当程序启动时，操作系统可能不会加载一个大程序

的所有模块。有些模块可能只在需要时加载，或者在 RAM 大小不足时将其交换到硬盘。

用户希望对简单的操作（如按键或鼠标移动）立即作出响应。如果因为它需要从磁盘加载模块或资源文件，导致响应延迟了

几秒钟，这对于用户来说是不可接受的。使用大量内存的应用程序会迫使操作系统将内存交换到磁盘。内存交换是鼠标移动

或按键等简单操作的响应时间长得不可接受的常见原因。

避免大量的 DLL，配置文件、资源文件、帮助文件等，分散再硬盘的不同地方。几个文件、最好和*.exe* 文件在同一个路径

下，这样是可以接受的。

3.6 动态链接和位置无关的代码

函数库可以是静态链接库（*.lib

，

*.a），或动态链接库，也称为共享对象（*.dll

，

* . so）。有几个因素可以使动态链接库比

静态链接库慢。这些因素将在14.11 静态库 VS 动态库中详细解释。

位置无关代码用于

类

Unix 系统中的共享对象。默认情况下，Mac 系统在任何地方都使用与位置无关的代码。位置无关的代

码效率很低，尤其是在 32位模式下，原因如14.11 静态库 VS 动态库中所述。

3.7 文件存取

读取或写入硬盘上的文件通常比处理文件中的数据花费更多的时间，特别是如果用户有一个病毒扫描程序，扫描所有要访问

的文件。

文件的顺序向前访问比随机访问快。读或写大块比一次读或写一小块文件更快。一次读写不要少于几千字节。你可以将整个

文件复制到内存缓冲区中，并在一个操作中读写它，而不是以非顺序的方式读写几个位。通常，访问最近访问过的文件要比

第一次访问快得多。这是因为文件已经复制到磁盘缓存。

远程或可移动媒体（如软盘和u盘）上的文件可能不会被缓存。这可能会产生非常戏剧性的后果。我曾经编写过一个

Windows程序，该程序通过调用 WritePrivateProfileString 来创建一个文件，它每写一行就会打开和关闭一次文件。由

于磁盘缓存，这在硬盘上工作得非常快，但是将文件写入软盘需要几分钟。

包含数字数据的大文件如果以二进制形式存储比以ASCII格式存储的文件更紧凑和高效。二进制数据存储的一个缺点是它不可

读，并且不容易移植到具有大端存储的系统中。

在具有许多文件输入/输出操作的程序中，优化文件访问比优化CPU使用更重要。如果处理器在等待磁盘操作完成时可以执行

其他工作，那么将文件访问放在一个单独的线程中可能会有好处。

3.8 系统数据库

在 Windows 中访问系统数据库可能需要几秒钟时间。与 Windows 系统中的大型注册数据库相比，将特定于应用程序的信息

存储在单独的文件中更有效。注意，如果使用 GetPrivateProfileString和WritePrivateProfileString 等函数读写配

置文件（*.ini 文件），系统可能会将信息存储在数据库中。

3.9 其他数据库

许多软件应用程序使用数据库来存储用户数据。数据库会消耗大量的 CPU 时间、RAM 和磁盘空间。在简单的情况下，可以

用普通的旧数据文件替换数据库。数据库查询通常可以通过使用索引、使用集合而不是循环等方式进行优化。优化数据库查

询超出了本手册的范围，但是你应该知道，优化数据库访问通常可以获得很多好处。

3.10 图形

图形用户界面可能使用大量的计算资源。通常会使用特定的图形框架。操作系统可以在其 API 中提供这样的框架。在某些情

况下，在操作系统 API 和应用程序软件之间有一个额外的第三方图形框架层。这样一个额外的框架会消耗大量额外的资源。

应用软件中的每个图形操作都通过调用图形库或 API 函数的函数调用实现的，然后这些函数调用设备驱动程序。对图形函数

的调用非常耗时，因为它可能经过多个层，并且需要切换到受保护模式并再次返回。显然，对绘制整个多边形或位图的图形

函数进行一次调用要比通过多次函数调用分别绘制每个像素或线条更有效率。

计算机游戏和动画中图形对象的计算当然也是很耗时的，特别是在没有图形处理单元的情况下。

各种图形函数库和驱动程序的性能差别很大。对于使用哪一种更好，我没有具体的建议。

3.11 其它系统资源

对打印机或其他设备的最好是一次写入大块内容，而不是每次一小块，因为对驱动程序的每次调用都涉及到切换到受保护模

式并再次返回的开销。

访问系统设备和使用操作系统的高级工具可能会很耗时，因为它可能涉及到加载几个驱动程序、配置文件和系统模块。

3.12 访问网络

一些应用程序使用Internet或内部网络进行自动更新、远程帮助文件、数据库访问等。这里所存在的问题是访问时间无法控

制。在简单的测试配置中，网络访问可能会很快，但在网络过载或用户远离服务器的使用情况下，网络访问可能很慢或完全

无法访问。在决定是在本地还是远程存储帮助文件和其他资源时，这些问题应该被列入考量之中。如果需要频繁更新，那么

最好在本地映射远程数据。访问远程数据库通常需要使用密码登录。对于许多辛勤工作的软件用户来说，登录是一个恼人的

耗时过程。在某些情况下，如果网络或数据库负载过重，登录过程可能需要一分钟以上。

3.13 访问内存

与对数据进行计算所需的时间相比，从 RAM 内存访问数据需要相当长的时间。这就是所有现代计算机都有内存缓存的原

因。通常，一级数据缓存为 8 ‐ 64Kb，二级缓存为 256Kb ‐ 2Mb。计算机中也有可能还存在一个三级缓存。

如果程序中所有数据的总和大于二级缓存，并且分散在内存中或以非顺序方式访问，那么内存访问可能是程序中最耗时的地

方。如果变量在内存缓存中，读写它只需要 2 ‐ 3 个时钟周期，如果不缓存，则需要几百个时钟周期。关于数据存储，请参

考 7.1 不同类型变量的存储；关于内存缓存，请参考 9 优化内存访问。

3.14 上下文切换

上下文切换是多任务环境中不同任务之间的切换，多线程程序中不同线程的切换，或大型程序中的不同部分的切换。频繁的

上下文切换会降低性能，因为数据缓存的内容，代码缓存、分支目标缓冲区、分支模式历史等都可能需要更新。

如果分配给每个任务或线程的时间片很小，上下文切换将会更频繁。时间片的长度由操作系统决定，而不是由应用程序。

在具有多个 CPU 或具有多核 CPU 的计算机中，上下文切换的数量会更少。

3.15 依赖链

现代微处理器可以乱序（错序）执行。这意味着如果软件指定 A 和 B 的计算，而 A 的计算速度较慢，则微处理器可以在计

算完 A 之前开始计算 B。显然，这只有在计算 B 不需要 A 的值时才有可能。

为了利用乱序执行的优势，必须避免长依赖链。依赖链是一系列的计算，其中每个计算依赖于前一个计算的结果。这会妨碍

CPU 同时执行多个计算或者导致混乱。有关如何打破依赖关系链的示例，请参见 11 乱序执行。

3.16 执行单元的吞吐量

延迟和执行单元的吞吐量之间有一个重要的区别。例如，在现代 CPU 上执行浮点加法可能需要 3 ‐ 5 个时钟周期。但每个时

钟周期可以开始一个新的浮点加法。这意味着，如果每个加法依赖于前一个加法的结果，那么每三个时钟周期只有一个加

法。但是，如果所有的加法都是独立的，那么每个时钟周期可以有一个加法。

在计算密集型的程序中，如果没有上面提到的耗时代码占主导地位，并且没有很长的依赖链，则性能才可能达到最高。在这

种情况下，性能受到执行单元吞吐量的限制，而不是延迟或内存访问的限制。

现代微处理器的执行核心分为几个执行单元。通常，有两个或多个整数单元、一个或两个浮点加法单元和一个或两个浮点乘

法单元。这意味着可以同时进行整数加法、浮点加法和浮点乘法。

因此，进行浮点运算的代码最好能够平衡加法和乘法。减法和加法使用相同的执行单位。除法需要更长的时间。在浮点操作

之间执行整数操作而不降低性能是可能的，因为整数操作使用不同的执行单元。例如，执行浮点运算的循环通常使用整数运

算来递增循环计数器、比较循环计数器与其极限等。在大多数情况下，可以假设这些整数操作不会增加总计算时间。

4 性能和可用性

更好的软件产品是可以为用户节省时间的产品。对于许多计算机用户来说，时间是一种宝贵的资源，许多时间浪费在速度

慢、难于使用、不兼容或容易出错的软件上。所有这些问题都是可用性问题，我认为应该从更广泛的可用性角度来看待软件

性能。

这不是一本关于可用性的手册，但是我认为有必要在这里引起软件编程人员注意一些影响软件使用效率的常见障碍。有关这

个主题的更多信息，请参见我在 Wikibooks 上提供的免费电子书Usability for Nerds。

下面的列表指出了一些让软件用户感到沮丧和浪费时间的典型原因，以及软件开发人员应该注意的一些重要的可用性问题。

1. 大型运行时框架。.NET 框架和Java 虚拟机框架通常比它们运行的程序占用更多的资源。这些框架是资源问题和兼容性问

题的常见来源，它们在框架本身的安装过程中、在框架下运行的程序的安装过程中、在程序启动过程中以及在程序运行

过程中都会浪费大量时间。使用这种运行时框架的主要原因是为了跨平台的可移植性。不幸的是，跨平台兼容性并不总

是如预期的那么好。我相信通过更好地标准化编程语言、操作系统和 API，可以更有效地实现可移植性。

2. 内存交换。软件开发人员通常拥有比最终用户拥有更多 RAM 的，功能更强大的计算机。因此，开发人员可能看不到过多

的内存交换和其他资源问题，对于最终用户，这些问题将会导致使用大量资源的应用程序表现很差。

3. 安装问题。程序的安装和卸载过程应该标准化，由操作系统而不是由单独的安装工具来完成。

4. 自动更新。如果网络不稳定或新版本有旧版本中不存在的问题，则软件的自动更新可能会导致问题。更新机制经常会弹

出一些烦人的弹出消息，比如请安装这个重要的新更新，或者在用户在忙于重要工作时，告诉它们要重启计算机。更新

机制不应该中断用户，而应该只显示一个独立的图标，表示有更新的可用，或者在计算机重新启动时自动更新。软件分

销商经常滥用更新机制来宣传其软件的新版本。这对用户来说很烦人。

5. 兼容性问题。所有软件都应该在不同的平台、不同的屏幕分辨率、不同的系统颜色设置和不同的用户访问权限上进行测

试。软件应该使用标准的 API 调用，而不是自定义的修改和直接访问硬件。应该使用现成的协议和标准化的文件格式。

Web 系统应该在不同的浏览器、不同的平台、不同的屏幕分辨率等环境中进行测试。应遵守可访问性指南。

6. 复制保护。一些复制保护方案是基于违反或规避操作系统标准的黑客攻击。这种方案是兼容性问题和系统崩溃的常见根

源。许多复制保护方案都是基于硬件识别的。当硬件更新时，这种方案会导致问题。大多数的复制保护方案都让用户感

到厌烦，并且阻止合法备份的复制，却没有阻止非法的复制。应该权衡复制保护方案的好处和在可用性和必要支持上付

出的成本。

7. 硬件更新。更改硬盘或其他硬件通常要求重新安装所有软件，并且还会丢失用户设置。花上整个工作日或者更多时间重

新安装的情况也很常见。许多软件应用程序需要有更好的备份功能，当前的操作系统需要更好的硬盘复制支持。

8. 安全。具有网络访问权限的软件易受病毒攻击和其他滥用的弱点，可能使用户付出极其昂贵的代价。而防火墙、病毒扫

描器和其他保护手段是造成兼容性问题和系统崩溃的最常见原因。此外，病毒扫描器比计算机上的其他任何东西都要花

费更多的时间，这种情况并不少见。作为操作系统一部分的安全软件通常比第三方安全软件更可靠。

9. 后台服务。许多在后台运行的服务对用户来说是不必要的，是对资源的浪费。考虑只在用户激活时运行服务。

10. 过多的特性。由于市场原因，软件通常会向每个新版本添加新特性。这可能会导致软件速度变慢或需要更多的资源，即

使用户从不使用过这些新特性。

11. 认真对待用户反馈。用户的抱怨应该被视为关于 bug、兼容性问题、可用性问题和所需新特性的有价值的信息来源。系

统地处理用户反馈，确保信息得到合理利用。用户应该得到关于问题调查和解决方案计划的回复。可以从网站上方便的

获得补丁。

5 选择最优算法

要优化 CPU 密集型软件，首先要找到最佳算法。算法的选择对于排序、搜索和数学计算等任务非常重要。在这种情况下，

选择最好的算法比优化想到的第一个算法，你可以得到更多的提升。在某些情况下，你可能需要测试几种不同的算法，以便

找到在一组典型测试数据上最有效的算法。

话虽如此，我必须提醒凡事不要过度。如果一个简单的算法可以足够快地完成这项工作，就不要使用高级和复杂的算法。例

如，一些程序员甚至使用哈希表来存储很小的数据列表。对于非常大的数据库，哈希表可以显著地提高搜索时间，但是对于

使用二分搜索甚至线性搜索的都可以很快完成的列表，就没有理由使用它。哈希表增加了程序的大小和数据文件的大小。如

果瓶颈是文件访问或缓存访问，而不是 CPU 时间，这反而会降低效率。复杂算法的另一个缺点是，它使程序的开发成本更

高，而且更容易出错。

对于不同目的的不同算法的讨论超出了本手册的范围。你必须查阅关于标准任务（如排序和搜索）的算法和数据结构的一般

文献，或针对更复杂的数学任务的特定文献。

在开始编写代码之前，你可以考虑其他人是否已经在你之前完成了这项工作。针对许多标准任务的优化函数库有许多种来

源。例如，Boost包含许多常用的经过良好测试的库。“Intel Math Kernek Library”包含许多函数用于常见的数学计算，包括线

性代数和统计学，以及“Intel Performance Primitives”库包含许多含函数用于音频和视频处理，信号处理、数据压缩和密码学

（www.intel.com）。如果你正在使用Intel 函数库，确保在非Intel 处理器上可以运作良好（参见 13.7 Intel 编译器中的 CPU

分派）。

在开始编程之前选择最优算法通常说起来容易做起来难。许多程序员已经发现，只有在他们将整个软件项目放在一起并对其

进行测试之后，才有更好的方法来处理问题。通过测试和分析程序性能以及研究瓶颈获得的见解，可以更好地理解问题的整

个结构。这种新的见解可以导致程序的完全重新设计，例如，当你发现有更好的方法来组织数据时。

对一个已经投入使用的的程序进行彻底的重新设计当然是一项相当大的工作，但这可能是一个相当好的投资。重新设计不仅

可以提高性能，还可以得到更易于维护的、结构良好的程序。实际上，你花在重新设计程序上的时间可能比你花在解决原来

设计糟糕的程序的问题上的时间要少。

6 开发过程

关于使用哪种软件开发过程和软件工程原则存在着相当多的争论。我不打算推荐任何具体的模型。相反，我将对开发过程如

何影响最终产品的性能发表一些评论。

在规划阶段，最好对数据结构、数据流和算法进行全面的分析，以预测哪些资源是最关键的。然而，在早期规划阶段可能有

许多未知的因素，因此很难对问题进行详细的概述。在后一种情况下，你可以将软件开发工作视为一个学习过程，其中主要

的反馈来自于测试。在这里，你应该为多次迭代的重新设计做好准备。

一些软件开发模型具有严格的形式，它要求在软件的逻辑架构中有几个抽象层。你应该知道，这种形式主义有其固有的性能

成本。将软件分割成过多的抽象层是降低性能的常见原因。

由于大多数开发方法本质上都是增量的或迭代的，所以一定要有一种策略来保存每个中间版本的备份。对于单人项目，制作

每个版本的 zip文件就足够了。对于团队项目，建议使用版本控制工具。

7 不同C++结构的效率

大多数程序员对于如何将一段程序代码转换成机器码以及微处理器如何处理这些代码，了解很少或者根本不了解。例如，许

多程序员不知道双精度运算和单精度运算一样快。谁会知道模板类比多态类更高效呢？本章旨在解释不同C++ 语言元素的相

对效率，以帮助程序员选择最有效的替代方案。本系列手册的其他卷进一步解释了理论背景。

7.1 不同类型变量的存储

剩余153页未读，继续阅读

qq_35176317

粉丝: 7
资源: 42

C++软件优化全攻略：Windows/Linux/DNC平台详解

Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms

C/C++ 编译器优化介绍

C＋＋代码优化方法总结

sw8dnc-sv13q软件有什么用

DNC-A2C结合算法

fanuc网线传输dnc

FANUC-DNC系统

dnc系统和mdc系统的区别

ubuntu上终端上mininet运行的网络拓扑上，dnc服务器地址查询命令行

traceroute 检查DNC解析是否正常

解释dnc1=wthresfunc(c,s,'hard',thr1c);

解释dnc2=wthresfunc(c,s,'soft',thr1c);

串口通过串口指令发送字符串“74HC138”,fpga实现三八译码器功能；发送字符串“calculator”，fpga实现加减乘除多功能计算器功能，发送字符串“enc-dnc”fpga是实现加密解密一体验证；

neo4j如何建立两层关系

spring批处理注意

使用分治法求出圆章的外圆方程c语言

Exception in thread "main" java.lang.ClassNotFoundException: org.postgresql.Driver

springboot 道闸

如何有url传参数对象

redis命令行获取数据

最新资源