【问题标题】:Reusing instances of objects vs creating new ones with every update重用对象实例与每次更新都创建新实例
【发布时间】:2015-04-29 15:12:03
【问题描述】:

每次我交换缓冲区时,重用对象实例与创建新实例之间有什么区别和陷阱?

背景:

这是我的一个游戏引擎项目。

我正在编写一个 TripleBuffer,其中每个对象都有三个版本:旧版本当前版本未来版本。这些对象的更改将通过从当前版本读取状态并将更改应用于未来版本来进行。在对所有对象(分别在适用的情况下)进行更改后,缓冲区将交换:未来对象变为当前对象,当前对象变为旧对象,而旧对象?

  • 要么被丢弃,并且将通过迭代现在当前对象来分配新对象
  • or 成为 now 未来的对象,它们的值将通过迭代 now更新(分别覆盖)当前对象。

解释:

  • “重用”:用新值覆盖旧实例的值,有效地改变实例的状态
  • “新实例/克隆”:使用旧实例的数据创建新实例,并对其应用更改

用例:

假设大约 1000 个对象以 30Hz 的频率进行交换,这意味着它们需要通过克隆当前的对象或重用现在已过时的最后旧对象(覆盖它们的所有状态)每秒重新创建 30 次。

它们的复杂程度可以从大约 5 个属性到数百个属性不等,并且总是具有 至少 2 个级别的深度

至少 2 个级别的深度 = 缓冲对象本身将仅包含构成它们的其他唯一对象的映射)

重新创建和重用都将要求迭代当前对象及其组件(短于:依次构成它们的对象)。

进一步考虑:

在引擎的其他部分,将使用对象的实时快照来触发事件和其他魔法。因此,重新创建或重用的决定将导致:

  • 重新创建意味着我可以安全地传递对对象的引用,因为对象在成为当前对象时将变得不可变
  • reusing 意味着我必须创建 当前对象 的副本或我进一步需要的任何部分,因为我不能保证事件(或其他)会在之前得到处理对象被重用

【问题讨论】:

  • 您一次要处理多少个对象?创建的成本是多少(比如它们有多少属性......初始化构造函数需要多长时间,它们将“有效”多长时间 - 即更新它们的频率)?....一般来说,我建议避免“重复使用”,除非它们是不可变的...... b/c 你有数据损坏的风险......你是否想提出垃圾收集策略?
  • 编写“性能良好”的代码通常是件好事;但请记住:除非您谈论的是时间要求严格的高性能计算应用程序......不要担心性能。相反:尝试编写易于理解和维护的代码。从这个意义上说:如果对象是不可变的(它们的内部状态在创建后是“固定的”);例如,您可以避免许多有关线程安全的问题。因此,我倾向于避免“重用”任何东西;除非您在这里谈论数百万个对象。

标签: java buffering


【解决方案1】:

除非您有充分的理由不这样做,否则请丢弃旧对象并创建新对象。

这将减少您出现各种错误的机会。例如,如果在其他地方引用了旧对象,重新使用它可能会产生不好的副作用。丢弃和创建新对象在概念上更简洁,并且可能会使代码更易于阅读、调试和维护。

在一般情况下,垃圾收集器也足够聪明,可以使丢弃和重新创建对象的成本不那么高。

在这种情况下,我会做的是编写最清晰、最直接的代码,这意味着在需要时创建一个新对象。然后我会对其进行测试,看看这是否是性能瓶颈,只有如果是,我才会考虑优化。换句话说,我会尽量避免premature optimization

【讨论】:

  • 这里的一个问题(我同意过早优化的主题)是,这个决定几乎决定了如何构建其余代码库;将添加一个示例/用例
【解决方案2】:

在 Graphics 中使用了一个缓冲区,因此您在尝试更新它时不会逐个像素地“绘制”到屏幕上。相反,您绘制到缓冲区,然后您可以一次交换整个图像。

我认为您使用缓冲区的原因类似。您不希望在处理“当前”对象时使用新更新的对象来修改它们,因为这会破坏当前对象的“图像”。

复用的优点:

  • 您没有丢弃尽可能多的内存,需要更少的垃圾收集
  • 您只需要更新已更改的对象

再创造的好处

  • 必须创建每个对象
  • 更简单更干净

您的最终决定将取决于性能与清晰度。重新创建所有对象的成本是多少?比较每个对象并只构建需要的对象是否更便宜?

即使比较对象或跟踪已更改的对象更便宜,但为了更简单而创建新对象可能是值得的,这正是@DaphnaShezaf's answer 的意义所在。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-01-23
    • 2018-09-11
    • 2018-06-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-10-21
    • 1970-01-01
    相关资源
    最近更新 更多