为什么在java中用一些数组(基本数据类型)替换对象(类)可以显著减少运行时间?

为什么在java中用一些数组(基本数据类型)替换对象(类)可以显著减少运行时间?,java,arrays,class,runtime,Java,Arrays,Class,Runtime,在我的课程中,我有以下课程: private static class Node { // True if '1', false otherwise (i.e. '0') public final boolean isDigitOne; // The number represented in the tree modulo the input number public final int val; // The pa

在我的课程中,我有以下课程:

   private static class Node
   {
      // True if '1', false otherwise (i.e. '0')
      public final boolean isDigitOne;

      // The number represented in the tree modulo the input number
      public final int val;

      // The parent node in the tree
      public final Node parent;

      public Node(boolean isDigitOne, int val, Node parent)
      {
         this.isDigitOne = isDigitOne;
         this.val = val;
         this.parent = parent;
      }
   }
我用另一个类的方法中的两个数组替换了这个类

boolean[] product0 = new boolean[num]; 
int[] product1 = new int[num];
程序的其余部分非常类似,类实现在需要时创建一个对象,而数组实现在执行开始时分配所需的最大内存

我测量两种情况下的运行时间

我注意到,对于较小的
num
,执行时间几乎相同。但是对于更大的值,数组实现运行得更快

以下是比较:

我的问题是为什么阵列实现运行得更快?

类实现在以下链接中作为“答案3”提供

很大一部分是由于数据在内存中的位置。对象数组不直接在内存中相邻存储数据,而是存储数据在内存中存储位置的引用。这意味着在访问数组位置并从数组中获取数据后,系统必须从内存中数组值所指向的位置获取数据。但是,基本数据数组将数据直接存储在数组中。这意味着系统只需进行一次查找即可访问数组,而不是两次查找即可访问数组然后访问对象。系统的运行速度通常非常快,对于较小的数据量来说,这一点并不明显,但当数据量增加时,这一点就会变得明显。

您正在比较苹果和桔子。数组是项的集合-节点类不是。用于遍历节点的集合是什么?您在计时中比较了哪些操作?您实际在执行哪些操作?我们不知道执行的是什么代码,因此无法推测为什么会有性能差异。我修改了我的问题以供参考@Dave Newton当你使用一个对象时,你也有很多对象创建,多个内存操作等等,相反,使用一个基元数组非常容易处理,当它在开始时间分配/创建一次时,时间是num的一个实例的完整程序的执行时间。我不想在这里重复完整的程序,我只是在这里添加了原始类表示的链接@阿米尔·阿富汗尼,你能更严格地定义“环顾四周”吗?引用就是引用。一个连续块可能比不连续块更快,这是有原因的——最好包括其中一个或多个原因,而不是挥手“环顾四周”:/@DaveNewton就可以了。我已经学习了RAM如何存储对象数组和它如何存储实际数据数组的细节,这已经有几年了。如果我在这一点上错了,请纠正我,但最大的区别是,对于对象集合,系统必须在从数组中获取位置后查找对象,而对于原语数组,值直接存储在数组中?这里我没有使用对象数组,而不是所有的对象都形成一个具有单个父节点的二叉树。我只是通过使用两个数组来有效地替换树结构。对于较小的num值,类实现所花费的时间较少,但是对于较大的num值,数组实现更快。正如我所说的,数组实现在开始时分配所需的最大内存(这可能不是一直需要的),但类实现将根据需要进行分配。@ManojBanik-Hmm,这很公平。我只能推测,这与运行一系列引用以查找下一个对象与运行一个数组以查找下一个引用之间的效率差异有关。如果系统必须从一个引用到下一个引用来查找树中的下一个对象,那么它的效率将低于计算数组中的偏移量来查找下一个引用。这是有意义的,好吧,我将测量程序不同部分的时间,以清楚地知道是哪个部分导致延迟。谢谢@蒂姆·亨特