【问题标题】:Which is faster: Array list or looping through all data combinations?哪个更快:数组列表或循环遍历所有数据组合?
【发布时间】:2015-12-21 00:59:35
【问题描述】:

我正在用 Java 编程,有关上下文,请参阅以下问题:Markov Model descision process in Java

我有两个选择:

byte[MAX][4] mypatterns;

或 ArrayList 我的模式

我可以使用 Java ArrayList 并在创建新数组时追加它们,或者通过计算所有可能的数据组合来使用静态数组,然后循环查看哪些索引是“打开或关闭”。

基本上,我想知道是否应该分配一个可能包含未初始化值的大块,或者使用动态数组。

我以 fps 运行,因此每帧循环 200 个元素可能会非常慢,尤其是因为我将有多个此循环的实例。

根据理论和我所听到的,动态数组非常低效

我的问题是:循环遍历一个包含 200 个元素的数组会比将对象附加到动态数组更快吗?

编辑>>>

更多信息:

  • 我会知道数组的最大长度,如果它是静态的。
  • 数组中的项目会经常更改,但它们的大小是恒定的,因此我可以轻松更改它们。
  • 静态分配它就像一个内存池
  • 其他实例的初始化数据可能比其他实例多或少

【问题讨论】:

  • 动态数组是指List,比如ArrayList?与普通数组相比,ArrayList 的效率非常低,是什么理论以及您在哪里听说的?不是。
  • 是的,我只是在编辑它。
  • ArrayList 我想可能不是低效的,但我听说静态数组要快很多倍。不知道这是不是真的,但我是这么理解的。
  • 虽然通常 ArrayList 是不可避免的,但在这种情况下我实际上可以选择,这就是我问这个问题的原因。
  • 使用ArrayList 而不是普通数组不太可能导致您遇到的任何性能问题。不要为此使您的代码复杂化,除非 Profiler 向您显示 ArrayList 导致性能下降。

标签: java performance dynamic-memory-allocation dynamic-arrays memory-pool


【解决方案1】:

你说得对,我应该先使用分析器,但我也只是对“理论上”的问题感到好奇。

“理论”太复杂了。有太多的替代方案(实现这一点的不同方法)需要分析。最重要的是,每种替代方案的实际性能将取决于硬件、JIT 编译器、数据结构的维度以及(真实)应用程序中对(真实)输入的访问和更新模式。

而且很有可能真的没关系

简而言之,没有人能给你一个理论上有根据的的答案。我们能给出的最好的建议是基于对性能的直觉和/或基于软件工程常识的建议:

  • 更简单的代码更容易编写和维护,

  • 编译器是比人类更一致的1优化器,

  • 花在优化不需要优化的代码上的时间是浪费时间。


1 - 当然是在大型代码库上。如果有足够的时间和耐心,人类可以在某些问题上做得更好,但这在大型代码库上是不可持续的,并且没有考虑到以下事实:1)编译器总是在改进,2)优化代码可以依赖于人类无法考虑的事情,并且 3) 编译器不会感到疲倦和出错。

【讨论】:

    【解决方案2】:

    迭代字节的最快方法是使用单个数组。处理这些的更快方法是 intlong 类型,因为一次处理 4-8 个字节比一次处理一个字节要快,但这取决于你在做什么。注意:一个字节[4] 在 64 位 JVM 上实际上是 24 个字节,这意味着您没有有效地利用 CPU 缓存。如果你不知道你需要的确切大小,你最好创建一个比你需要的更大的缓冲区,即使你没有使用所有的缓冲区。即在 byte[][] 的情况下,您使用的内存是您真正需要的内存的 6 倍。

    【讨论】:

    • 你的意思是字节大小,还是字节数?我认为内存对齐在 Java 中是 8 的倍数?
    • @bigcodeszzer 对象的默认内存对齐方式为 8 个字节。但是,如果您想要一个紧凑且高效的数据结构,您需要一个 byte[] 或类似的所有数据,以便每个字节只使用字节。
    • 哦,我明白了,我想我可以这样做并使用 i+=4 或其他东西循环。
    【解决方案3】:

    当您在ArrayList 上设置initialCapacity 时,任何性能差异都将不可见。你说你的收藏的大小永远不会改变,但如果这个逻辑改变了呢? 使用ArrayList,您可以访问很多方法,例如contains

    正如其他人已经说过的,使用ArrayList,除非性能基准表明这是一个瓶颈。

    【讨论】:

      猜你喜欢
      • 2019-07-10
      • 1970-01-01
      • 1970-01-01
      • 2013-02-12
      • 2017-03-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-27
      相关资源
      最近更新 更多