跟进Beta1和DevLab对VC项目转换绩效的反馈-yiteyi-C++库

你好，

null

我的名字叫Bogdan Mihalcea，我是C++项目和开发团队的开发人员。在过去的2年中，我研究了一个新的C++项目系统，它是在MSMube之上构建的。

我写这个博客是为了分享一些关于自Beta1构建以来我们对项目转换性能所做改进的好消息。这是可能的，因为我们从你那里得到的反馈，我要感谢你这么做！

在我们的开发里程碑期间，有测试报告说，对于特定类型的项目，我们的转换非常缓慢。它们通常包含许多文件（1000+），其中很大一部分包含文件级配置。在分析了根本原因和修复成本之后，我们假设这些具有许多文件级配置的项目并不常见，因此在这种情况下对性能的影响很小。我们做的另一个假设是，这种转换是一次性的，所以即使对那些罕见的情况影响很大，它也是一次性的税。基于这些假设，我们将修复的优先级降低，并决定投入时间使主线场景的性能更好。

我们的团队有一个客户计划，其中包括通过Beta1提前发布产品，并与客户举行各种面对面的会议。其中一个事件是Visual C++ + DeVlab，上次我们在09五月保存。在这个事件中，我们发现20%的客户正在经历非常缓慢的转换。

我们调查并意识到，所有案例都是由解决方案中不到5%的项目引起的，这些项目占用了大部分转换时间。关于这几个项目的一个常见细节是，它们在文件级配置上非常繁重。通过与客户的讨论，我们意识到由于各种原因（进化的代码库、批量选择容易导致人为错误、以前转换中的错误、将文件级配置还原到项目级的批量方式不容易），很不幸很容易进入这种状态。

这就大大否定了我们的假设，即客户可以拥有1000多个文件的项目，而超过一半的项目具有文件级配置的情况并不常见。从我们与客户的讨论以及从Beta1的客户那里得到的反馈来看，第一个假设也无效，这表明，即使有这种情况的项目不是很常见的不幸的是，这是常见的客户与数百个项目有1或2个这样的，这将影响整个经验的转换为一个更大的百分比的客户，比我们估计早些时候。

此外，第二个假设受到了质疑，我们从您的反馈中了解到，转换可能不是一次性的税，因为大多数公司喜欢在两个产品上并行开发的双重状态中停留数月，并且通常只保留以前的版本文件作为更改和更改的基线每次使用新产品时都要重新转换。考虑到我们在Dev10中添加的新特性，本地多目标，这似乎使这种方法更加流行。

在我们得到所有这些反馈之后，我们采取了行动。我们分析了代码路径，找到了可以针对这种情况进行优化的地方，并进行了修复。下面是一个节选，从我们的测量之前和之后的修复。

项目

文件/vcproj

配置

%%vcproj中包含文件配置的文件

上一次转换时间

电流转换时间

客户

~4000

50%%

55分钟