【问题标题】:Optimization of a GC language, any ideas?GC语言的优化,有什么想法吗?
【发布时间】:2011-07-06 14:13:03
【问题描述】:

在优化方面,我是一个相当大的新手。在我正在开发的当前游戏中,我设法优化了一个功能并减少了大约 0.5% 的 CPU 负载,这和我之前一样“棒极了”。

我的情况如下:我使用名为 ExEn 的 XNA 包装库在 MonoTouch 中开发了一款重物理游戏,并尽我所能尝试我发现很难让游戏在 iPhone4 上达到可玩的帧率(此时甚至不想考虑 iPhone3GS)。

性能下降几乎肯定是在物理计算中,如果我关闭物理,帧速率会急剧上升,如果我禁用一切,渲染,输入,音频,只是让物理性能在物理密集型情况下徘徊在 15fps 左右。

我使用 Instruments 来分析性能,这就是我得到的:http://i.imgur.com/FX25h.png 消耗最多性能的函数要么来自物理引擎(Farseer),要么来自它们调用的 ExEn XNA 包装函数(尤其是 Vector2.Max, Vector2.Min)。

我研究了这些函数,我知道 Farseer 在哪里可以通过引用而不是通过值将值传递给这些函数,所以这就是我能想到的唯一方法。这些函数本身基本上很简单相当于

这样的操作
return new Vector2(Max(v1.x, v2.x), Max(v1.y, v2.y)) 

基本上,我觉得自己陷入了困境,而且我的能力和对代码优化的理解有限,我不确定我的选择是什么,或者我什至有什么选择(也许我应该蜷缩成胎儿的姿势哭泣? )。打开 LLVM 并内置发布后,我最多只能获得 15fps。我确实设法通过降低物理精度将游戏提高到 30fps,但这使得许多关卡根本无法玩,因为身体彼此相交并坍塌。

所以我的问题是,这是一个失败的原因还是我可以做些什么来提高性能?

【问题讨论】:

  • 我认为您不应该关注库函数,而应该关注调用它们的函数。这些函数很简单,这意味着您经常调用它们。查看代码并问自己:为什么我这么频繁地打电话给他们?当然,分析器应该告诉您应该关注代码的哪些部分
  • 函数调用来自物理引擎,调用如此频繁的原因是物理引擎在每个更新周期都需要获取场景中所有物体的AABB盒子并检查交叉点。物理引擎本身由比我聪明得多的人进行了高度优化,所以我不确定在这方面我能做些什么。
  • 请记住,每次创建“新 Vector2”时,GC 都必须在某个时候回收它。进行就地替换可能会更好:“target.x = Max(v1.x, v2.x); target.y = Max(v1.y, v2.y);”。
  • Vector2 是一个结构体,应该由堆栈而不是 GC 处理。如果是这样,那么我会说无论你做什么,单声道都不会给你在单声道上的 Farseer 物理提供良好的性能。如果单声道工作正常,只要您不动态添加/删除主体/几何体,Farseer 就应该以零分配/解除分配运行。
  • 专注于路口检测。特别是如果你周围有很多物体,你可能需要找到一个局部交叉点例程(在一步中彼此相距很远的物体......实际上不会在下一步重叠,是吗?)。

标签: c# iphone mono xna xamarin.ios


【解决方案1】:

首先,喜欢你在 Windows Phone 7 上的游戏!

其次,我在您的分析器输出中没有看到任何异常。我对 Farseer 引擎进行了一次快速而肮脏的性能分析(在 .net 中运行)并得出了类似的结果。看起来你的减速几乎是成比例的,可能是由于单声道本身。

【讨论】:

  • 感谢您的反馈,是的,我最担心的事情可能会浮出水面:D 我只是真的想确保性能看起来相似(即没有可以避免的巨大瓶颈)。但从你所说的情况来看,这不太可能。
【解决方案2】:

我想你已经遵循http://farseerphysics.codeplex.com/documentation 中的性能提示了:-)

  • 最重要的似乎是 为了降低复杂性 碰撞检测计算, 即不是视觉而是碰撞 形状。在 Unijty3D 中,它们被称为 对撞机,您可以附加一个简单的 立方体作为复杂人类的对撞机 身体。我什么都不知道 更贵,但他们可能有类似的 概念(是不是叫body?)。

    如果可能,请尝试更换您的主 字符或其他复杂对象 简单的立方体并检查 fps 是否提高。

  • 编译器开关有时会影响性能。确保没有激活调试设置(我在 C++ 库项目中达到了30 times slower code)。确保打开了armv7优化和-O3或-Os

  • 注意日志语句,因为它们在 iPhone 上非常昂贵

[更新:]

  • 尝试减少主动计算的 AABB 的数量,以找出物理引擎的哪个部分导致了问题。如果是纯数字,请遵循 FFox 的建议。

  • 其他平台的情况如何?你在开发阶段在哪里进行测试,在模拟器上?哪一个?有机会让它在 Android 或 Android 模拟器或 Windows Phone 上运行吗?如果这是 iPhone 特有的问题,这会给你一个提示。

  • 啊,我刚刚看到ExEn还处于预发布状态,最终将于7月21日作为操作系统推出。 IMO 这改变了情况:如果您的应用程序在其他类似平台上运行良好,那么只需等待发布并重新尝试。很有可能您正在开发的预发布版本中仍有调试代码。

【讨论】:

  • 是的,我很遗憾地说我已经研究了你提到的所有内容,但我仍然发现性能不足:(仍然感谢您的回答!
  • 我真的为你感到难过。当我做这个图书馆的事情时,我度过了几天的沮丧。但我们不想放弃:)我已经更新了答案
  • @Kay: (背景:我写了ExEn)-实际上ExEn中的数学类型已经达到了发布标准,没有调试代码。我没有也不会真正计划在最后一个周期中分析和挤出 - 但它们当然不应该“慢”。他们没什么。 (我在 iOS 上也遇到过同样的物理问题 - 在微型 iPhone CPU 上运行物理是很痛苦的。我能做的最好的事情就是显着减少场景中的接触点数量。)
  • @Andrew:很酷的项目:) 与药物问题相关:你知道在 Windows Phone 7 和 iPhone 上比较相同代码的性能吗?
  • @Kay 恐怕不行。不过,了解 Mono + iPhone 的表现会很有趣。我确实假设 MonoTouch 编译器的质量相当好。
猜你喜欢
  • 2023-03-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多