机器翻译的效果测试：Visual Studio 2008在Visual C++中的性能改进

原文地址： http://blogs.msdn.com/vcblog/archive/2007/11/12/performance-improvements-in-visual-c.aspx

下面来看看不同的自动网页翻译的效果吧！

首先是微软的自动翻译： Windows Live 翻译 Beta

在 VisualC ++  中性能改进

大家好，我的名称是 Jim Springfield，我是架构师 VisualC ++  团队上。  我最近花两个月处理某些核心改进如何 VC 处理智能感知以及整个用户界面响应。

我们观察到一个强之间这些性能问题的严重程度和大小的项目和解决方案出现这些问题相关。  因此，我们与一些大型 ISV 客户用户已报告问题与我们的 IDE 合作密切。  这些客户通常必须使用的解决方案通过一个  100  项目包含成千上万的文件。  虽然我不能识别它们按完整名称，我想先向他们提供一个 shout 出，然后感谢他们的时间和精力它们。  因此，感谢您对 Bob、 Don、 DickBarden，Rainer，Kelly 和 Mike，您知道您是谁。

我已工作在这些更改为一个快速修复工程修补程序 （或，“ QFE ”）  for  Visual Studio  2005 ，我已还跟踪更改为 Visual Studio  2008  “ Orcas，” 和我快乐要报告的所有这些更改将 VS2008 中可用，以及一个可公开获得 QFE 中可用时 （也称为一个普通分发版本，或 “ GDR ”) 为 VS2005。

可以从下面的链接下载 GDR。  您将被提示您第一次与 Windows Live ID 或 Passport 登录并再转到实际的下载位置。 http: // connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=9436

我希望我可以说这些区域中的所有内容是固定作为我们的努力的一部分。  但是，实际情况是，没有一些问题，需要更多大量工作并这是不可能完成在此时间框架。  我们已经正在下一个版本超出了 VS2008 和解决这些问题将我们的顶部优先级之一。  我们是从根本上更改如何我们方法智能感知，我们正在设计与最大的解决方案记住。  我们将网络日志有关此项工作将，因此观看此空间有关其他信息这些工作，因为我们正在做的工作是非常有趣的方向。

为了让您感觉为作用域我们对解决这些问题在 VS2005 和 VS2008 中的所做的更改，此项工作涉及  46  源文件在三个 DLL 的。  总体， 4664  的代码行被更改或添加。  我想利用此机会，使您一段深入的问题我们发现和解决方案我们实现性质。

不同的锁实现用于访问 NCB （智能感知）

.NCB 文件 （一个在内存中的智能感知数据） 受到保护与简单的关键节，以防止从多个线程同时访问。  但是，通常没有多个线程，只是想要阅读信息 NCB，不修改它，以便我们替换多 reader -/  单个的编写器锁 NCB 关键节。  这允许多个线程读取 NCB 一次它就会发生这种情况在后台线程中发生的智能感知请求和前台线程需要同时访问它时。  一个典型示例此问题已获得 QuickInfo 工具提示。  前台线程需要执行一些基本的查询的 NCB 以创建 QuickInfo 请求，它将然后处理在后台线程。  但是，如果后台线程已经有锁，然后在前台将阻塞，直到背景已完成。  这是真正明显滚动围绕一个大的函数时。  与自动完成请求以及发生类似的问题。

减少的 “ 掷 - away ” 请求数

快速导航周围文件时, 我们将生成 QuickInfo 和 CodeDefintionWindow （如果该窗口已打开） 请求如光标涉及不同领域的代码。  这可能导致大量的背景请求，将在运行，然后被忽略。  我们进行了更改为只允许这些类型的项目之一队列中的一次。
改进的速度更改活动的配置和其他选项时

没有几件事情都非常慢，不足以解决方案中更改。  修改某些选项 （如添加一个包含目录） 或更改活动的配置将需要一个真正长时间对于大型解决方案。  没有正在运行在这些情况下它已被移除或重做一些真正效率很低工作。

转到定义方面的改进

“ 转到定义 ” 在许多情况下，将分析文件为光标，以便知道确切的类型的标识符在光标下。  这是发生在前台线程上，如果有在后台线程运行的是低优先级项目前, 景色将必须等待一个用于完成后台。  这已更改为队列项背景队列，这会导致任何低优先级项目到被中止。 此项工作的结果我们有一个客户向  10 - 20  秒报告两分钟延迟拉。

降低 CPU 占用

有是现在限制的后台线程执行的分析大多数时。  即使后台运行在较低优先级，没有考虑一下使用  100 % 的 CPU 和某些报告它会干扰其他应用程序的问题。  我们现在处理低优先级背景项目 （如智能感知填充） 使用仅  ~ 80 % 的 CPU 的时间。  在这段时间仍将处理任何高优先级项目 （即智能感知请求）。
在项目中文件查找

我们更改项目系统，以便查找更为有效项目中的文件。  这提高了几个方案如将文件添加到项目，更改配置，等等。

状态栏中的详细信息

现在，没有在状态栏中显示更多信息。  它如下所示：  “ 更新 Intellisense… (xxx) ”。   数字在括号中的显示多少个后台线程工作项正在进行。  为客户的不是查看智能感知以往完成，此信息可能会非常有用。
等待光标

我们现在时间时 IDE 可能无法立即响应显示等待光标。  这提供了更好的反馈到用户，IDE 不只是挂起，并可能显示在下列情况下：

·         关闭一个项目

·         当一个前台分析 “ 转到定义 ” 调用或需要

·         加载一个解决方案并执行初始化后

·         在配置更改后 reparsing 解决方案

改进了空闲时间处理

我们对进行大量的对如何 IDE 处理它的空闲时间处理进行了改进。  此项工作涉及到对确保空闲任务由 IDE，启用运行 longer - 空闲任务是通过多个空闲循环，分布并确保我们的空闲逻辑是智能，可以时更高优先级任务正在等待中断早期的更高版本完成处理这样的低优先级。  总体，这些更改使整个 UI  /  编辑体验更加平滑。

添加到项目文件的映射

查找一个项目中的文件已做只是线性搜索文件。  进行某些操作如将一个文件添加到一个项目已经包含大量文件时，这导致大瓶颈。
其他性能和正确性方面的改进

·         我们发现几个内部算法的表现出性能 （即 O(N ^ 2 ) 或 O(N ^ 3 )) 大型扩展和替换这些与算法更多的线性。

·         我们找到实例正在使用多线程方案中的函数静态数据并将此数据移到线程本地存储了这些线程安全的。

·         我们改进性能的一个内部哈希表用 better - performing 哈希函数出现较少的冲突。

公开一种机制来控制某些方面的智能感知

有些客户已经学习了通过标记为只读 NCB 文件或从 vcpackages 目录，删除智能感知引擎，feacp.dll，来手动禁用智能感知但有还没有一种方法控制任何这从 IDE。  使用此 QFE，时我添加几个标志，可以使用 VS 宏的执行操作 （如几乎完全禁用智能感知或不允许对 NCB 更新，同时允许查询设置。  第二个模式对于大型项目的位置智能感知工作，是很有用的但 reparsing 是痛苦非常非常有用。  您可以立即禁用更新直到您已经完成一组编辑然后打开它并获取所有内容分析最新。  控制这些设置的宏可以将附加到工具栏按钮进行方便的访问编码时。  给定多长时间该项已经处于，我将编写一个单独的网络日志对此很快。

接下来再来看看Google的自动翻译效果： Google语言工具

性能方面进行了改进在vc中

喜，我的名字是吉姆斯普林菲尔德，我是一个建筑师对视觉的 c  +   +  团队，我最近花了两个月时间工作，对一些核心，以改善风险投资如何处理intellisense以及整体用户界面的响应。

我们观察到一个很强的关联性与严重性，这些性能问题，而且规模的项目和解决方案展示这些问题，作为一个结果，我们一直与一些大的独立软件开发商的客户，他们汇报的问题，与我们的集成开发环境，这些客户通常有解决方案有超过一百个项目数以千计的档案。虽然我不能确定他们的全名，我想给喊出来给他们，并感谢他们所付出的时间和精力，所以，谢谢你给鲍勃，唐，迪克， rainer凯利，迈克，你知道你是谁。

而我的工作对这些变化是一个快速解决工程补丁（或者是 "  qfe  "  ）为visual studio  2005  ，我也跟踪这些改变对视觉工作室， 2008年 " 海怪 "  ，我很高兴向大家报告说，所有这些变化将可在vs2008以及提供一份可公开提供qfe （又称普遍分发新闻稿，或 " 东德 "  ）为vs2005 。

东德可从下面的链接，你会被提示登录与windows live的身份证或护照的第一，然后再采取实际的下载位置。 http: // connect.microsoft.com/visualstudio/downloads/downloaddetails.aspx?downloadid = 9436

我想我可以说一切都在这些领域是固定的，作为我们努力的一部分，但现实情况是，也有一些问题需要更大量的工作，哪些是不可能完成的，在这一时间框架，我们已经对下一版本以后vs2008和解决这些问题将是我们的一项首要工作，我们是从根本上改变我们如何intellisense和我们正在设计与最大的解决方案牢记，我们将会对博客的方向，这项工作正在进行中，所以看这空间，为更多的资料，这些努力，作为我们工作在这里做的是相当有趣。

给你一种感觉：变动范围的，我们为了解决这些问题，在vs2005和vs2008下，这项工作涉及46个源文件跨越三个dll文件的。总体而言， 4664行代码被修改或补充，我想借着这个机会向大家作一个有点洞察本质问题，我们找出和解决办法时，我们执行。

不同的锁，执行获取国家协调机构（ intellisense ）

协调机构档案（在记忆intellisense数据），是受保护的一个简单的关键路段，以防止同时接入多线程，但往往有多个线程只是想要看的资料，协调机构，而不是修改它，所以我们更换国家协调机构的关键路段与multi - reader / single - writer锁，这使得多线程读协调机构，在同一时间内可以发生时intellisense要求，是对发生的背景线程和前台线程需要访问它作为良好。一个典型的例子是造成这一问题得到quickinfo tooltip 。前台线程将需要做一些基本的查询的协调机构，以创造quickinfo要求，届时将会处理后台线程，但如果背景线程已经有锁，那么前景会堵塞，直到背景是做了，这是真正引人注目的滚动时左右，一个大的功能。类似的问题发生autocomplete要求以及。


压缩了一批 " 扔离家出走 " 的要求

当快速航行约一个文件时，我们会产生quickinfo和codedefintionwindow （如果窗口被打开）请为光标触及不同地区的代码，这可能导致在这群背景要求，将运行，然后再被忽视，我们取得了改变了只允许一个这种类型的项目在排队的时间。

提高速度时，改变积极的配置和其他选择

有几件事当时令人难以置信的变化缓慢，在一个解决办法。修改某些选项（例如加入一个包含目录）或变更积极配置将采取真的长的时间，大量的解决方案。存在着某些真的低效正在进行维修工作，在这些案件，其中已拆除或重做。

转到定义改善

" 转到定义 "  ，在许多情况下，将解析文件，以光标，以了解确切的类型标识符下光标，这是发生在前台线程，如果有一个低优先项目的背景，主线，前面将要等待的背景之一，以完成这个转变为以队列该项目的背景，队列，其中的原因有低优先项目胎死腹中。 由于这项工作，我们有一个客户报两分钟的延误下降到10 - 20秒。

降低cpu消费

现在是节流的背景线程时，做大部分的解析，即使背景是运行在较低优先，有关心它采用100 ％的中央处理器和一些报道问题的干涉，它与其他应用程序，我们现在进程低优先级的背景项目（ intellisense这样的人口）仅利用 ?   80  ％的cpu的时间，任何高优先项目（即intellisense要求）仍然会处理在这段时间内。

档案查找项目

我们改变了计划系统，使查找档案，在项目更为有效，这提高了几个情景，如加入档案，以项目，改变配置等。

更多信息，在状态栏

人们现在更多的信息显示在状态栏上，它看起来是这样的：  " 更新intellisense … （三十）  "  。数目在括号内显示出多少背景线程工作项目正在进行当中。客户可以看到的，并非intellisense有史以来完成，这种信息可能是有益的。

等待光标
我们现在展示等待光标的时候排未必能立即作出反应，这给了更好的反馈，以对人说的ide不只是红，并有可能显示在下列情况作出说明：

·实施关闭破产项目

· "  转到定义 "  ，是引用或者当一个前景解析需

·加载后，解决问题的办法，这样做初始化

·解决后，配置变更


改进的空闲时间处理


我们提出了多种改善措施，以怎样的ide处理其闲置时间处理这项工作所涉及的变化，以确保较低优先闲置任务是这样看待由集成开发环境，使长期闲置的运行任务，以尽可能分散，在多闲置周期，并确保我们的闲置逻辑足够聪明来突破，为早日完成后，当一个更高的任务，就是在等待。总体而言，这些变化使整个用户界面  / 编辑体验顺畅。

地图档案的补充，以项目
查找档案，在一个项目正是这样做线性搜索的档案，这造成了大怠工的时候做某些业务，如加入文件到一个项目，已经包含了很多文件。


杂项性能和正确性改善

·我们发现了一些内部算法，展出表现欠佳（如为o （ n  ^   2  ）或为o （ n  ^   3  ） ）在大型和更换这些与算法，规模更为线性。

·我们发现的功能，静态数据被用于多线程的情况，并提出这些线程安全的，由提出这项数据，以线程局部存储。

·我们的表现有所改善内部哈希表，以更好地履行散列函数表示，展品少的碰撞。

暴露出机制来控制某些方面的intellisense

一些客户已经学会手工禁用intellisense标记协调机构档案，作为唯读或删除intellisense引擎， feacp.dll ，从vcpackages目录，但一直没有办法控制任何一本从集成开发环境，而工作关于这个qfe ，我增加了几颗旗认为，可以设置使用与宏说，这样做的东西，例如致残intellisense几乎完全或不准更新，以协调机构，同时允许疑问。第二模式是相当有用的大型项目的intellisense工程，是有益的但reparsing是痛苦的，你现在可以禁用更新，直到你完成的一群编辑，然后把它和尽解析不断更新。宏说，控制这些设定，可以连接到工具栏按钮，为方便群众，而编码既然有多久，本条目已经是，我会写一个单独的博客关于这个很快。 

再下来看看worldlingo的效果吧（部分）： Worldlingo

在Visual C ++ 的表现改善

喂，我的名字是吉姆·斯普林菲尔德，并且我是一位建筑师在Visual C ++ 队。 我在一些核心改善上最近度过了运作对怎样的二个月VC成交与Intellisense并且整体UI快速响应。

我们观察了这些性能问题和项目的大小显示这些问题的严肃和解答之间的一种强的交互作用。 结果，我们严密工作了与报告问题与我们的IDE的一些大ISV顾客。 这些顾客典型地有解答以在包括数以万计的一百个项目文件。 当我不可能鉴别他们通过全名时，我想要给呼喊他们和感谢他们他们的时间和努力。 如此，谢谢对鲍伯，唐，迪克， Rainer，凯利，并且麦克，您知道谁您是。

当我在这些变动工作作为一个快速修复工程学补丁(或， “QFE”)时为视觉演播室2005年，我也跟踪变动为视觉演播室2008年“海怪”，和我是愉快报告所有这些变动将是可利用的在VS2008以及可利用在公开地可利用的QFE (也称一般发行发行或者“GDR”)为VS2005。

GDR可以从链接被下载如下。 您将被提示首先登录与窗口活ID或护照然后采取对实际下载地点。 http: // connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=9436

我祝愿我可能说一切在这些区域被固定作为我们的努力的部分。 然而，现实是有需要更加坚固的工作，并且无法完成在这时间表的有些问题。 我们在下发行已经工作在VS2008之外，并且论及这些问题将是我们的一件最优先考虑的事。 我们根本上改变怎么我们接近Intellisense，并且我们在头脑里设计用最大的解答。

 最后来看看yahoo吧： Yahoo!翻译

对不起, 翻译请求出错.

错误原因:  无法获取你要翻译的页面: http: // blogs.msdn.com/vcblog/archive/2007/11/12/performance-improvements-in-visual-c.aspx

错误代码:   148

就以上这个简单的例子来看，微软的自动翻译已经做的相当不错，尤其对于与计算机相关的术语翻译，做的相当好。相对而言，Google就差得多了。至于Yahoo！，就只能是无语了。有兴趣的话，可以自己试试，看样子机器翻译要达到人工翻译的程度，至少还需要五十年。