如果您想要在您的计算机上重新创建该测试结果，您需要做以下的事情：
如果您需要改变测试参数，例如最大计算数或协议文件的位置，请编辑 THRDPERF 示例工程中的 Threadlibtestview.cpp，然后重新编译生成该应用程序。（请注意，要编译生成该应用程序，您的计算机需要对长文件名的支持。）
请确保文件 Thrdlib.dll 在一个 Threadlibtest.exe 能够链接到它的位置。
如果您想要使用 Microsoft Excel 来查看测试的结果，请确定 Microsoft Excel 已经正确地被安装在运行该测试的计算机上。
从 Windows 95 或 Windows NT 执行 Threadlibtest.exe，并且从"Run performance tests"菜单选择"Run entire test set"。正常情况下，测试运行一次要花费几个小时才能完成。
在测试结束之后，检查结果时，既可以使用普通文本协议文件 C:\Temp\Results.fil ，也可以使用工作单文件 C:\Temp\Values.xls。请注意，Microsoft Excel 的自动化（automation）逻辑并不自动地为您从原始数据生成图表，我使用了几个宏来重新排列该结果，并且为您生成了图表。我憎恨数字（number crunching），但是我必需称赞 Microsoft Excel，因为即使象我一样的工作表妄想狂（spreadsheet-paranoid），也可以提供这样漂亮的用户界面，在几分钟之内把几列数据装入有用的图表。
我所展现的测试结果是在一个 486/33 MHz 的带有 16 MB RAM 的系统收集而来的。该计算机同时安装了 Windows NT (3.51 版) 和 Windows 95；这样，在两个操作系统上的不同测试结果就是可比的了，因为它们基于同样的硬件系统。
那么，现在让我们来解释这些值。这里是总结计算结果的图表；后面有其解释。该图表应该这样来看：每一个图表的 x 轴有 6 个值（除了有关长计算的消耗时间表，该表仅含有 5 个值，这是因为在我的测试运行时，对于非常长的计算计时器溢出了）。一个值代表多个计算；我以 2、5、8、11、14 和 17 个计算来运行每一个测试。在 Microsoft Excel 结果工作表中，您将会找到对于基于CPU的计算和基于I/O的计算的线程的每一种计算数目的结果，延迟（delay bias）分别是 10 ms、30 ms、90 ms、270 ms,、810 ms 和 2430 ms，但是在该图表中，我仅包括了 10 ms 和 2430 ms 的结果，这样所有的数字都被简化，而且更容易理解。
我需要解释 "delay bias." 的含义，如果一个测试运行的 delay bias 是 n，则每一个计算都有一个倍数 n 作为其计算时间。例如，如果试验的是 delay bias 为 10 的 5 个计算，则其中一个计算将执行 50 ms，第二个将执行 40 ms，第三个将执行 30 ms，第四个将执行 20 ms，而第五个将执行 10 ms。并且，当这些计算被串行执行时，假定为最糟的情况，所以具有最长延迟的计算首先被执行，其他的计算按降序排列其后。于是，在"理想"情况下（就是说，计算之间没有重叠），对于基于CPU的计算来说，全部所需的时间将是 50 ms + 40 ms + 30 ms + 20 ms + 10 ms = 150 ms。
对于消耗时间图表来说，y 轴的值与毫秒对应，对于响应时间图表来说，y 轴的值与相对（relative turnaround）长度（即，实际执行所花费的毫秒数除以预期的毫秒数）相对应。
基于 I/O 的任务
以消耗时间和 turnaround 时间来衡量，基于 I/O 的线程当并发执行时比串行执行要好得多。作为计算得一个功能，对于并发执行来说，消耗时间以线性模式递增，而对于串行执行来说，则以指数模式递增。
请注意，这个结论与我们前面对基于 I/O 的计算的分析是一致的，基于 I/O 的计算是多线程的优秀候选人，因为一个线程在等待 I/O 请求结束时被挂起，而这段时间该线程不会占用 CPU 时间，于是，这段时间就可以被其他的线程所使用。
对于并发计算来说，平均响应时间是一个常数，对于串行计算来说，平均响应时间则线性递增。
请注意无论任何情况，只有少数几个计算执行的方案中，无论串行或并发的执行，无论测试参数如何设置，并没有什么明显的区别。
基于 CPU 的任务
正如我们前面所提到的，在一个单处理器的计算机中，基于 CPU 的任务的并发执行速度不可能比串行执行速度快，但是我们可以看到，在 Windows NT 下线程创建和切换的额外开销非常小；对于非常短的计算，并发执行仅仅比串行执行慢 10%，而随着计算长度的增加，这两个时间就非常接近了。以响应时间来衡量，我们可以发现对于长计算，并发执行相对于串行执行的响应增益可以达到 50%，但是对于短的计算，串行执行实际上比并发执行更加好。
Windows 95 和 Windows NT 之间的比较
如果我们看一看有关长计算的图表，我们可以发现在 Windows 95 和 Windows NT 下其行为是极其类似的。请不要被这样的事实所迷惑，即好象 Windows 95 处理基于I/O的计算与基于CPU的计算不同于 Windows NT。我把这一结果的原因归结为这样一个事实，那就是我用来决定多少个测试循环与 1 毫秒相对应的算法（如前面所述）是非常不精确的；我发现同样是这个算法，在完全相同的环境下执行多次时，所产生的结果之间的差异最大时可达20%。所以，比较基于 CPU 的计算和基于 I/O 的计算实际上是不公平的。
Windows 95 和 Windows NT 之间不同的一点是当针对短的计算时。对于并发的基于I/O的短计算，Windows NT 的效果要好得多。我把这一结果得原因归结为更加有效率得线程创建方案。请注意，对于长得计算，串行与并发I/O操作之间的差别消失了，所以这里我们处理的是固定的、相对比较小的额外开销。
对于短的计算，以响应时间来衡量，请注意，在 Windows NT 下，在10个线程处有一个断点，在这里更多的计算并发执行有更好的效果，而对于 Windows 95 ，则是串行计算有更好的容量。
请注意这些比较都是基于当前版本的操作系统得到的（Windows NT 3.51 版和 Windows 95），如果考虑到操作系统的问题，那么线程引擎非常有可能被增强，所以两个操作系统之间的各自行为的差异有可能消失。但是，有一点很有趣的要注意，短计算一般不必要使用多线程，尤其是在 Windows 95 下。
建议
这些结果可以推出下面的建议：决定多线程性能的最主要因素是基于 I/O 的计算和基于 CPU 的计算的比例，决定是否采用多线程的主要条件是前台的用户响应。
让我们假定在您的应用程序中，有多个子计算可以在不同的线程中潜在地被执行。为了决定对这些计算使用多线程是否有意义，要考虑下面的几点。
如果用户界面响应分析决定某些事情应该在第二线程中实现，那么，决定将要执行的任务是基于I/O的计算还是基于CPU 的计算就很有意义。基于I/O的计算最好被重新定位到后台线程中。（但是，请注意，异步单线程的 I/O 处理可能比多线程同步I/O要好，这要看问题而定）非常长的基于CPU的线程可能从在不同的线程中被执行获益；但是，除非该线程的响应非常重要，否则，在同一个后台线程中执行所有的基于 CPU 的任务可能比在不同的线程中执行它更有意义。请记住在任何的情况下，短计算在并发执行时一般会在线程创建时有非常大的额外开销。
如果对于基于CPU的计算 - 即每一个计算的结果只要得到了就立刻能应用的计算，响应是最关键的，那么，您应该尝试决定这些计算是否能够以升序排序，在此种情况下这些计算串行执行的整体性能仍然会比并行执行要好。请注意，有一些计算机的体系结构的设计是为了能够非常有效率地处理长的计算（例如矩阵操作），那么，在这样的计算机上对长的计算实行多线程化的话，您可能实际上牺牲了这种结构的优势。
所有的这些分析都假定该应用程序是运行在一个单处理器的计算机上，并且计算之间是相互独立的。实际上，如果计算之间相互依赖而需要串行设计，串行执行的性能将不受影响（因为串行是隐式的），而并发执行的版本将总是受到不利的影响。
我还建议您基于计算之间相互依赖的程度决定多线程的设计。在大多数情况下子计算线程化不用说是好的，但是，如果对于拆分您的应用程序为多个可以在不同线程处理的子计算的方法有多种选择，我推荐您使用同步的复杂性作为一个条件。换句话说，如果拆分成多个线程而需要非常少和非常直接的同步，那么这种方案就比需要使用大量且复杂的线程同步的方案要好。
最后一个请注意是，请牢记线程是一种系统资源，不是无代价的；所以，there may be a greater penalty to multithreading than performance hits alone. 作为第一规则（rule of thumb），我建议您在使用多线程时要保持理智并且谨慎。在多线程确实能够给您的应用程序设计带来好处的时候才使用它们，但是，如果串行计算可以达到同样的效果，就不要使用它们。
总结
运行附加的性能测试套件产生了一些特殊的结果，这些结果提供了许多有关并发应用程序设计的内部逻辑。请注意我的许多假定是非常基本的；我选择了比较非常长的计算和非常短的计算，我假定计算之间完全独立，要么完全是基于I/O的计算，要么是完全基于CPU的计算。而绝大多数的现实问题，如果以计算长度和 boundedness 来衡量，都是介于这两种情况之间的。请把本文中的材料仅仅作为一个起点，它使您更加详细地分析您的应用程序，以决定是否使用多线程。
在本系列的将来的一篇文章中，我将讨论通过异步I/O来增强基于I/O的操作的性能。
