gpt4 book ai didi

java - 返回或参数中的某种性能问题 (Java)

转载 作者:行者123 更新时间:2023-12-02 00:28:21 26 4
gpt4 key购买 nike

我正在运行一个复杂的多线程java游戏,除了这个函数之外,它运行得很好。当调用此函数时,大约有 0.01% 的时间会导致四分之一秒的线程中断。通过一系列的调试线和时间测量,这绝对取决于这个函数(以及其他三个几乎完全相同的函数)。

此函数的用途是在体素引擎游戏中提供附近 block 的光照水平。它仅在世界的一部分更新时运行,这可以与渲染同时发生。

请注意:

  • 此函数 100% 准确地实现其预期功能。
  • 此函数在 0.01% 的时间中会导致大约四分之一秒的线程中断。
  • 变量不同步。
  • 该函数在程序中一次不会被多次调用。
  • 所有变量都是较大的非同步类的有效字段。
  • 所有变量均为整数。
  • 数组 light[][][] 是一个 byte[][][]
  • 此方法一次不会被多次调用,因为它是由较大的方法在很宽的时间间隔内同步的。

我很确定外部同步不是问题。

该函数的哪些部分可能会导致线程同步、CPU 过度使用或堆栈填充问题,以及如何提高性能以消除这些渲染问题?

public byte nsleftlighting(int[] coords){
if(coords[0]<0)return 16;
difx=chunkedx-chunks[coords[0]].X;
difz=chunkedz-chunks[coords[0]].Z;
if(coords[1]==0){
if(-difx<=-(chunklimit)){return 16;}

else if (-difx==0) {
if(-difz>=0){
proz=0;
specialz=-difz;
}else{
specialz=difz-1;
proz=1;
}
if(chunks[chunkxyid[1][proz][0][specialz]].loaded){
return chunks[chunkxyid[1][proz][0][specialz]].light[15][coords[2]][coords[3]];
}
else{return 16;}
} else {
if(-difz>=0){
proz=0;
specialz=-difz;
}else{
specialz=difz-1;
proz=1;
}
if(-difx>0){
prox=0;
specialx=-difx-1;
}else{
specialx=difx;
prox=1;
}
if(chunks[chunkxyid[prox][proz][specialx][specialz]].loaded){
return chunks[chunkxyid[prox][proz][specialx][specialz]].light[15][coords[2]][coords[3]];
} else {return 16;}
}
}
if(coords[1]>0){
return chunks[coords[0]].light[coords[1]-1][coords[2]][coords[3]];
}
return 16;
}

最佳答案

Java 中的多维数组不保证在内存中连续排列(我不确定一维数组是否明确保证连续,但实际上它们是连续的) 。因此,根据访问元素的方式,CPU 缓存可能必须经常更新(与访问一维数组中连续或附近的元素相反,作为整个数组或至少一个数组,访问一维数组中的连续或附近的元素相当快)它的连续 block 可以立即加载到缓存中;此外,较新的 JVM 实现可以在一些简单但不复杂的情况(循环)中优化索引绑定(bind)检查,这使得数组访问几乎与任何语言中的访问一样快(C))。到底发生什么取决于 JVM 实现和内存管理器。请参阅this供引用。

因此,与手动映射的一维数组相比,使用多维数组通常会造成性能损失,但在这种情况下几乎无法解释四分之一秒的延迟。如果数组真的很大,是否可以交换到磁盘缓存?

关于java - 返回或参数中的某种性能问题 (Java),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9613467/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com