阅读此问题，我发现这是(请注意引号)"代码"以解决问题(顺便说一下，这是perl)。

100,{)..3%!'Fizz'*%!'Buzz'*+\or}%n*

显然，这是一个理性的例子，没有真实的含义(我希望永远不要在真实的代码中看到)，但是，当我们必须做出选择时，何时牺牲代码的可读性以提高性能？我们是否仅应用常识，是否总是将其作为最后的手段？你有什么策略？

编辑：很抱歉，看到答案我可能表达得很不好(英语不是我的母语)。我并不是说仅在编写代码后才考虑性能与可读性，而是在编写代码之前询问一下。有时我们可以通过做一些更暗的设计或者提供一些使类更暗的属性来预见将来的性能改进。我们可能会决定使用多个线程或者仅使用一个线程，因为我们希望此类线程可以为我们提供可伸缩性，即使这样做会使代码更难以理解。

解决方案

回答

我总是从我能想到的最易读的版本开始。如果性能有问题，请重构。如果可读性版本难以一概而论，则可以重构。

关键是要进行良好的测试，以便重构。

我认为可读性是代码中排名第一的最重要问题，尽管正确工作仅次于第二。

回答

选择可读性而不是性能，除非可以证明需要性能。

回答

我要说的是，只有在存在已证明的重大性能问题时，才应该牺牲性能的可读性。当然，"重要"是关键所在，重要的和不重要的不应该针对我们正在处理的代码。

回答

可读性是最重要的。对于现代计算机，只有最苛刻的应用程序中最密集的例程才需要过多地担心性能。

回答

我采用常识，这种事情只是工程需要进行的无数折衷之一，而且我看不到一些特殊的特征。

但更具体地说，绝大多数以表演为名的人在做怪异的，难以理解的事情时，他们过早地进行了评估。

回答

我们应该始终首先阅读。系统的形状通常会随着开发而发展，而真正的性能瓶颈将是意料之外的。仅当我们运行系统并且可以看到由探查器或者其他此类工具提供的真实证据时，才会显示出优化的最佳方法。

"如果你着急，那就走很长的路。"

回答

Programs must be written for people to read, and only incidentally for
  machines to execute. 
   — Abelson & Sussman, SICP

编写良好的程序可能更易于分析，从而提高性能。

回答

"过早的优化是万恶之源。"唐纳德·克努斯(Donald Knuth)

回答

在需要优化的时候，我宁愿牺牲紧凑性并保持性能增强。 perl显然有一些深层次的东西可以用来寻找简洁/性能比，但是写单行代码虽然很可爱，但是来维护代码的人(根据我的经验，通常我自己是6个月后)可能更喜欢采用扩展样式的内容，如此处所述：

http://www.perl.com/pub/a/2004/01/16/regexps.html

回答

我认为绩效可能是一个问题的过程：

• 让它起作用。
• 讲清楚。
• 测试性能。
• 如果存在有意义的性能问题：重构速度。

请注意，这不适用于在以后阶段更难更改的高级设计决策。

回答

同意以上所有内容，但也：

当我们决定要优化时：

• 在语法之前修复算法方面的内容(例如，不要在大型​​数组中进行查找)
• 确保我们证明自己的改变确实可以改善一切，衡量一切
• 评论优化，以便下一个看到该功能的人不会将其简化为从头开始的地方
• 我们可以预先计算结果还是将计算移到可以更有效地完成的地方(例如数据库)

实际上，只要我们能在优化的代码中发现晦涩的错误比简单的显而易见的代码难得多且令人讨厌，就保持可读性

回答

可读性总是赢。总是。除非不是这样。那应该很少。

回答

过早的优化规则也有例外。例如，当访问存储器中的图像时，读取像素不应成为离线功能。并且在图像上提供自定义操作时，切勿这样做：

typedef Pixel PixelModifierFunction(Pixel);

void ModifyAllPixels(PixelModifierFunction);

取而代之的是，让外部函数访问内存中的像素，尽管比较丑陋。否则，我们一定要编写慢速的代码，无论如何稍后都必须重构它们，因此我们需要做更多的工作。

至少，如果我们知道要处理大图像，那就是事实。

回答

我最喜欢这个问题的答案是：

• 让它起作用
• 改正它
• 快一点

在事情的范围内，除了下一个不得不照顾代码的傻瓜之外，没有人对可读性有所抱怨。但是，话虽如此...如果我们对艺术很认真，并且这是一种艺术形式，我们将始终努力使代码成为可能表现出的最高性能，同时仍可被他人阅读。我的朋友和导师(从各个方面来说都是坏蛋)曾经在一次代码审查中亲切地告诉我："傻瓜只写他们能理解的代码，而天才则写任何人都可以理解的代码。"我不确定他从哪儿得到的，但这一直困扰着我。

参考