阅读这个问题，我发现这是（注意引号）解决问题的“代码”（顺便说一句，这是 perl）。
100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*
显然，这是一个没有实际意义的智力示例（我希望永远不会在我的生活中的真实代码中看到这一点），但是，当你必须做出选择时，你什么时候牺牲代码可读性来换取性能？你是否只应用常识，你总是把它作为最后的手段吗？你的策略是什么？
编辑：我很抱歉，看到我可能表达的问题的答案很糟糕（英语不是我的母语）。我并不是说仅在您编写代码之后才意味着性能与可读性，我也在您编写代码之前询问过。有时，您可以通过进行一些更暗的设计或提供一些使您的类更暗的属性来预见未来的性能改进。您可能会决定使用多个线程还是只使用一个线程，因为您期望这些线程可能为您提供可伸缩性，即使这会使代码更难理解。
在我认为性能可能成为问题的情况下，我的流程：
请注意，这不适用于后期更难更改的更高级别的设计决策。
我总是从我能想到的最易读的版本开始。如果性能有问题，我会重构。如果可读版本难以概括，我会重构。
关键是要有好的测试，这样重构就容易了。
我认为可读性是代码中#1 最重要的问题，尽管正确工作紧随其后。
可读性是最重要的。对于现代计算机，只有要求最苛刻的应用程序中最密集的例程才需要过多地担心性能。
这个问题我最喜欢的答案是：
在事情的范围内，除了下一个必须照顾您的代码的倒霉傻瓜之外，没有人对可读性提出废话。然而，话虽如此……如果您对自己的艺术很认真，并且这是一种艺术形式，那么您将始终努力使您的代码具有最高的性能，同时仍可供其他人阅读。我的朋友和导师（在各个方面都是 BADASS）曾经在一次代码审查中慷慨地告诉我“傻瓜写的代码只有他们能理解，天才写的代码任何人都能理解。” 我不确定他从哪里得到的，但它一直困扰着我。
必须编写程序供人们阅读，并且只是偶然地供机器执行。
— Abelson & Sussman，SICP
编写良好的程序可能更容易分析并因此提高性能。
您应该始终首先考虑可读性。系统的形状通常会随着您的开发而发展，而真正的性能瓶颈将是意想不到的。只有当您让系统运行并且可以看到真实的证据（由分析器或其他此类工具提供）时，才会显示优化的最佳方法。
“如果你赶时间，就绕远一点。”
同意以上所有，但也：
当您决定要优化时：
实际上，尽可能地保持可读性——在优化的代码中发现晦涩难懂的错误比在简单明显的代码中更难也更烦人
我运用常识——这类事情只是工程学所需要的无数权衡之一，而且我能看到的特殊特征很少。
但更具体地说，绝大多数以性能为名做奇怪而难以理解的事情的人过早地做这些事情并且没有衡量。
除非你能证明你需要性能，否则选择可读性而不是性能。
我会说，如果存在已证明的显着性能问题，您应该只牺牲性能的可读性。当然，“重要”是那里的问题，重要的和不重要的应该特定于您正在处理的代码。
“过早的优化是万恶之源。” ——唐纳德·克努斯
可读性总是赢。总是。除非它没有。这应该很少见。
有时需要优化时，我宁愿牺牲紧凑性并保持性能增强。perl 显然有一些深水可以探索简洁/性能比，但就像编写单行代码一样可爱，来维护您的代码的人（根据我的经验，通常是 6 个月后的我自己) 可能更喜欢扩展风格的东西，如此处所述：
过早优化规则也有例外。例如，当访问内存中的图像时，读取一个像素不应该是一个离线功能。并且在为图像提供自定义操作时，永远不要这样做：
typedef Pixel PixelModifierFunction(Pixel);
void ModifyAllPixels(PixelModifierFunction);
相反，让外部函数访问内存中的像素，尽管它更丑陋。否则，您肯定会编写慢速代码，以后无论如何都要重构，因此您正在做额外的工作。
至少，如果您知道要处理大图像，那是正确的。