我与许多以视频游戏为生的人合作。我对C ++有相当多的了解，我知道在日常编程中可以使用的一些通用性能策略。就像使用前缀++ / - 而不是post fix。
我的问题是，人们常常来找我给他们提供关于他们在编程时可以定期进行的一般优化的提示，但这些人经常用各种语言编程。有些使用C ++，C＃，Java，ActionScript等。
我想知道是否有任何一般性能提示可以在日常编程基础上使用？例如，我建议使用其他语言编写前缀++ / - postfix，但我不确定这是否属实。
我的猜测是它是特定语言的，一般优化的最佳方法是确保你没有使用主要的膨胀算法，但也许有人有一些建议。
答案 0 :(得分：1)
没有进入语言细节，甚至不知道这是嵌入式，网络，CAD，游戏还是iPhone编程，没有太多可以说的。我们所知道的是，涉及多种语言，并且由于某些未知的原因，性能总是比期望慢。
首先，检查您的算法。慢速算法会导致可怕的性能。阅读算法及其复杂性。
其次，请注意是否存在任何非常慢的操作，例如点击数据库或传输信息或移动机器人手臂。看一下程序是否正在做更多的事情。
第三，简介。如果有一部分代码占用了5％的时间，那么优化不会使您的程序速度提高5％以上。如果一部分代码占用了大量时间，那么值得一看。
第四，让某些人知道他们正在做什么来进行任何特定的优化。完成后测试它们以确保它们确实加快了性能。当性能成为一个问题时，我已经通过一些违反直觉的措施来改进它，比如卷起循环。
答案 1 :(得分：0)
我认为你不能将优化概括为此类。要优化执行时间，您需要深入了解语言并了解事情的详细信息 。只是猜测或假设其他语言的经验是行不通的！例如，编写x = x << 1而不是x = x*2可能是C ++的一大好处。在JavaScript中，它会降低你的速度。
由于所有语言之间存在所有差异，因此很难找到通用的优化技巧。也许对于某些相似的语言（例如C＃和Java）。但是，如果你将JavaScript和Python添加到该列表中，我很确定不会有很多常见的优化技术遗留下来。
还要记住，过早优化通常被认为是不好的做法。开发人员的时间比购买额外的硬件要贵得多。
但是，有一个一个的东西浮现在脑海中。在过去十年左右的时间里，对象关系映射器已经变得非常流行。因此，它们出现在（d）几乎所有流行的语言中。但你必须小心这些。如果没有正确配置，很容易将大量数据加载到内存中，您将永远不会在代码中使用这些数据。记在脑子里。延迟加载可能会有所帮助。但你的里程 会有所不同。
优化取决于很多事情，回答这样一个普遍的问题会使这篇文章爆炸成一篇完整的论文。在我看来，应该逐个项目地考虑优化。不仅是语言基础。
答案 2 :(得分：0)
我认为您需要将其分为两个单独的问题：
1）是否存在与语言无关的发现性能问题的方法？是。个人资料，但avoid the myths around that subject。
2）是否存在与语言无关的修复性能问题的方法？它取决于。
一般语言不可知原则是：在做（2）之前做（1） 换句话说，Ready-Aim-Fire，而不是Ready-Fire-Aim。
Here's an example of performance tuning，在C中，但它可以是任何语言。
答案 3 :(得分：0)
自从问这个以来我学到了一些东西：
I / O操作通常是性能最高的。当您进行磁盘或网络I / O时（通常是最昂贵的，因为如果您必须等待来自其他主机的响应，您必须等待远程主机执行的所有处理和I / O操作） ）。仅在绝对必要时才执行这些操作，并且可能在可能时考虑使用缓存。
由于网络/磁盘I / O以及与SQL之间的转换时间，数据库操作可能非常昂贵。使用内存数据库或缓存可以帮助减少I / O问题，一些（并非所有）NoSQL数据库可以减少SQL转换时间。
仅记录重要信息。使用log4j之类的日志库可以提供帮助，因为您可以在应用程序中将日志记录放在心中，但是您将每条消息设置为某个日志级别。无论您将应用程序设置为哪个日志级别，都只会记录该级别或更高级别的消息。这样，如果您需要对功能进行故障排除，您只需更改快速配置并重新启动应用程序即可为您提供其他消息。然后，当您完成后，只需将应用程序恢复到默认级别，这样就不会太频繁地记录。
仅包含所需的功能。额外的功能可能很好，但可能会增加处理时间，为应用程序提供额外的失败位置，并使您的团队开发时间花费在更重要的任务上。
正确使用和配置内存管理器。如果未正确配置垃圾收集例程可能会导致性能下降。如果您的应用程序每隔一分钟冻结一两秒进行垃圾回收，您的客户可能会不满意。
仅在发现性能问题后才能配置文件。 Profilers会使应用程序性能看起来比实际情况更糟，因为您的应用程序和分析器在同一主机上运行，消耗相同的硬件资源。
不要过早地进行性能调整。您可以采用一般的做法，在每种语言中都应该提高性能，但是在应用程序开发过程中启动性能调优可能会使您在开发过程中花费很多，因为仍然需要添加功能。
这不一定有助于提高性能，但将类依赖性保持在最低限度。当你进入性能调优时，很有可能你必须重写代码的整个部分，如果你在性能调优部分有很多依赖，你就有更大的机会破坏代码。它通常可能是多米诺骨牌效应，因为在修复性能问题之后，您必须修复所有依赖项，以及可能的原始依赖项的依赖项。对于具有大量依赖关系的应用程序，几个小时的性能调优练习估计很快就会变成几个月。
如果需要考虑性能，请不要使用解释性语言（脚本语言）。
仅使用您需要的硬件。拥有64核处理器的系统可能看起来很酷，但如果您的应用程序中只运行两个或三个线程，那么从64核处获得的好处不大。事实上，在极少数情况下，过度使用硬件有时会损害性能，因为必须连接芯片来处理所有硬件，这会导致应用程序花费更多时间在核心或处理器之间切换而不是实际处理。
< / LI>您报告的所有时间指标都尽可能精细。目前，您可能只需要担心进程所需的毫秒数，但将来随着您的应用程序越来越快，您可能需要更精细的计时。如果版本A使用毫秒而版本B使用微秒，那么如果版本B花费大约相同的毫秒数，如何比较性能。版本B可能更好，但您无法分辨，因为版本A没有使用足够精细的指标。