培养一个每个人都可以尝试任何想法以使软件运行更快的时间？

有时，通过方法和彻底的搜索可以发现软件性能的窍门。有时，需要疯狂的思维和勇气尝试疯狂的想法。有时，一个想法只是开始，需要大量的努力。

如何营造一个每个人都可以尝试不同想法以改善我们正在开发的软件性能的时间？团队中的每个人都有至少几个月的软件使用经验，并且非常擅长该软件。

您是否同意不同的想法将有助于找到提高软件性能的方法？为什么？为什么不？

哪些技术可以使我们快速尝试优化想法？为了从试用中获得良好的结果，是否需要快速的编码速度？

最后，应分配多少“时间”以确保良好的结果而又不会造成懈怠？

是否有必要进行实验以证明存在“做某事的更快方法”？（添加2011-06-07）

有关：

• 您有什么策略巧妙地提高团队水平？
• 什么时候代码黑客会变得糟糕？

（仅出于赏金目的， -2011 / 06/07团队规模为2-4个开发人员，无专门的质量检查人员。所有代码，单元测试和性能测试均由开发人员完成。由于项目的性质，探查器结果可用于显示比例执行时间，即使它没有显示出单个瓶颈。）

最好的选择是使用探查器识别热点，并（作为一个团队）讨论如何修复热点。

您必须能够衡量和记录改进（因此，这不仅仅是疯狂的猜测），并且作为一个团队来进行，可以确保人们知道正在修复的问题以及如何修复问题。

让程序员在代码库中疯狂地破解想法，意味着您无法控制正在发生的事情以及它是否有效。

程序员往往很聪明又有创造力（因为这是任何擅长编程的先决条件），因此在解决问题时让他们尝试各种想法总是很有益的。但是，在尝试提高性能时，有两点需要牢记（我假设“性能”是指降低执行速度）：

• 算法优化的工作往往比其他任何事情都要好。举一个简单的例子，无论您对Bubblesort实现如何做，只要有足够的数量，Quicksort的极慢实现最终都会更快。
• 除非您测量（配置文件）并根据结果进行任何操作，否则与性能相关的任何事情都是完全荒谬的。

我的主要观点是，在开始一段时间的野心试验之前，确保您与每个人都在同一页面上是很重要的。事后发现您经验不足的同事正在尝试永远无法解决的事情（您可能会事先告诉他们），总是很遗憾。

可悲的是，我不能凭经验说话。但是我听说Atlassian有一天允许员工随心所欲地做自己的事情，并在某种聚会气氛中表达自己的想法。显然对他们来说结果很好。但是我必须同意安德森（Andersen）的观点，即说到绩效，创意和开箱即用的想法不那么重要，而是分析哪些过程花费的时间最多。也许，一旦您对系统进行了概要分析，就可以给每个人一天的时间来提出有关如何帮助加快该过程的重要部分的想法。他们提出想法后，您可以选择尝试哪些想法。

我们在以前的一些团队中所做的一个成功的实践是“深潜”的概念。一些人会聚在会议室，确定一些用户场景，然后开始逐步执​​行代码或查看探查器日志。在某些情况下，数据清楚地表明了瓶颈，使我们可以说服怀疑论者相信他们自己的代码中确实存在性能问题！为了使此成功，我们遵循一些关键原则：

1. 尝试着眼于可能出现瓶颈的关键方案或代码路径。不要在优化那些不需要优化的东西上浪费时间（如果它没有损坏……）
2. 保持小组人数少，并专注于最了解代码的人员。不要忘记包括该功能的测试人员和项目经理-他们具有关键的见识，可以从参与或收集信息中受益，以更好地进行测试。
3. 通过让区域所有者给出高层架构框图和区域概述来开始会话。关键组件是什么，并简要描述它们的作用。一旦我们深入研究代码，您会惊讶于框图中有多少次没有反映现实。（实际报价：“我不知道我们仍在使用该组件。我以为几年前就摆脱了！”）
4. 期望找到功能错误以及性能问题。这是好事。另外，期望有时您不会发现任何重要的事情。那也是一件好事。
5. 期望有几个长时间的会议。这些是工作会议。感到舒适，并通过它工作。所有人都可以协作进行更长时间的扩展时，您会做更多的事情。
6. 做笔记，好笔记。如果使用缺陷跟踪数据库，请考虑立即打开问题以进行跟踪，即使这些问题的优先级较低。

避免让整个团队参与“绩效推动”。由于ThorbjørnRavn Andersen 在另一个答案中提到的原因，这些通常没有管理层期望的结果。在某些领域，您会获得巨大收益，而在人们不熟悉的其他领域，您将获得回归，因此很难预测/追踪您说“完成了”应该获得多少收益。与管理层的对话充满挑战。

您可能需要提高软件速度的原因是，如果其中的某些内容明显很慢。如果不是这种情况，那么优化就是浪费时间。但是，如果某件事很慢，则执行任务。

...为了完成任务，按以下顺序执行两个步骤：

1. 查看执行任务的函数是否有效编写。它的算法好坏吗？是否以有效的方式访问数据库。一次可以循环100次吗？通常，简单地检查代码可以找到一个障碍，不仅可以解决它，而且可以同时使您成为更好的程序员。

2. 不要在第一个数字上花费一个多小时左右的时间。如果一个小时内找不到问题，请使用探查器查找有问题的地点。知道问题点后，您可以回到第1步，然后再做一次，以找出改善所识别代码的最佳方法。

通常（**），您无法通过实验获得更好的性能。

你明白了

• 知道如何进行简单，有效的设计。如果您弄错了这一部分，则实验不会有太大的不同。例如，知道如何分辨何时使用代码生成器是一种成功的设计方法。

• 知道如何通过定位a）昂贵的活动，以及b）可以用更好的东西替代的活动来调整软件。每个人都知道您应该“使用探查器”，但这还不够。

选中此答案以回答其他问题。

**例外可能是与硬件相关的严格代码，例如图形渲染，处理器管线或CUDA行为，或者尝试网络或DB协议，而您只需要熟悉使用它的最佳方法即可。

添加：大型系统的许多程序员都感到有些惊奇。这是因为在大型的结构良好的程序中，可能会出现大型的，看不见的性能问题，并且探查器无法找到它们，因为它们没有本地化到例程中。它们是程序一般结构的一部分，即使程序可以以最佳方式完成也是如此。

仅举一个具体的例子，这是一个带有源代码（在C ++中）可以完成工作的程序。它是从我研究过的真实C程序中提取的。

它做什么，它的目的是要做些什么，而分数的时间是不是真的有必要吗？可以加快多少？

好吧，在该程序的第一个版本中，看起来完全合理且非本地（对探查器不可见）的内容花费了33.3％的时间。替换后，该时间被节省了，这是该程序的第二个版本。

在该程序的第二个版本中，可以删除的其他内容（对于任何事件探查器都不可见）花费了16.7％的时间。删除它导致了版本3。

在版本3中，删除了13％。剩下的66％被删除了。在那之后剩下的东西中，有61％被删除了！

最后，从那之后剩下的东西中，删除了98％！

那么，总体情况如何？在原始程序花费的每1000个周期中，有多少个被删除？998！

每个程序都是不同的，但是根据我的经验，每个大型程序都有一系列分析程序无法找到的耗时的问题，手动采样可以解决，而且如果程序员真正追求最大性能，则可以将其删除大加速。