CODEWITHSUNDEEP
javamultithreadingperformance
Sean
Sean

Reputation: 254

Performance hitches of some sort in a return or parameter (Java)

I am running a complicated multithread java game, which is working perfectly with the exception of this function. This function, when called, approximately 0.01% of the time, will cause a thread hitch of a quarter of second. Through a series of debug lines and time measurements, it's absolutely down to this function (and three others almost exactly like it).

The usage of this function is to provide the light level of a nearby block within a voxel engine game. It is only run when a section of the world is updated, which can happen alongside rendering.

Please note:

I'm pretty sure external synchronization is not the issue.

What part(s) of this function may be causing an issue with thread synchronization, CPU overuse, or stack filling, and how can I go about improving performance to get rid of these render hitches?

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;
}

Upvotes: 0

Views: 101

Answers (2)

Joonas Pulakka
Joonas Pulakka

Reputation: 36577

Multidimensional arrays in Java are not guaranteed to be laid out in the memory contiguously (I'm not sure if 1-dimensional arrays are specifically guaranteed to be contiguous either, but in practice they are). Therefore, depending on how you access the elements, the CPU cache might have to be updated quite often (as opposed to accessing successive or nearby elements in an 1-dimensional array, which is quite fast, as the whole array, or at least a contiguous block of it, can be loaded to cache at once; additionally, newer JVM implementations can optimize index bound checks away in some simple - but not complex - cases (loops) which makes array access almost as fast as it can be in any language (C)). What exactly happens depends on the JVM implementation and the memory manager. See this for a reference.

So, using multidimensional arrays as opposed to manually mapped 1-dimensional arrays is generally a performance penalty, but would hardly account for quarter-second delays in this case. If the arrays are really big, could it be swapping to disk cache?

Upvotes: 2

Gray
Gray

Reputation: 116938

I don't see anything in here that would cause a performance problem -- at least not with that high a variance. Array accesses should be extremely fast -- even if they are 4 dimensional arrays. [[Nice effort on that.]]

A quarter second is not a huge amount of time which makes me wonder if the profiler is lying to you about the source of the problem. It may be responding poorly to the multi-dimensional arrays or some other attribute of this method that is not immediately apparent -- to me at least.

One possibility, however remote, is that your program is swapped and these arrays are pretty big. If they aren't accessed very often is there any chance you are seeing some IO as some memory pages are swapped in?

You commented that you are using wall-clock timers to determine that the routine takes 250ms. Are you sure that the CPU was actually executing that method for that time period? Could this be a thread contention issue that is taking over CPU in some other part of the program? Can you see if you see CPU spikes every so often when this method takes a long time?

Any chance you are seeing a GC heap lock and it's affecting the array accesses more than other routines? Can you watch the memory graphs to see if you see a correlation? Does giving the program more heap affect the timing or the frequency of the problem? This is going to be more an issue if you are running Java <= 1.5.

Upvotes: 1

Related Questions