File IO blocks rendering

Performance Tuning
#1

Hi,

I am experiencing a strange behaviour which I was wondering if anybody knows about. When I read from a BufferedReader in a separate Thread, the rendering speed goes noticeable down. Actually rendering seems to block. I was tracking it down to peaks in:

  • LoaderThread: calls to .readLine
  • RenderThread: calls to glVertex3f

Does anybody know about this behaviour and what would be the solution? Might using Vertex Arrays help or does the bus block on Java File IO in general?

Thanks alot!
Mezzerman.

#2

Even if it would block the bus, file-I/O is normally so slow that it should have any impact.

Maybe you’re using synchronized-blocks/methods.

Are you creating a new Thread everytime you do File I/O? Thread-construction is a very heavy operation.

What are you doing with the results obtained from readLine, any processing?

Last thing I can come up with is that you’re creating lots of garbage while doing I/O, and the GC starts to kick in full-sweeps very often, if the Heap is already nearly (>95%) full.

#3

Thanks for the quick reply!!!

The FileIO-Thread is obtained from a ThreadPool using java.util.concurrent. I can increase the speed by omitting the readLine method call and can reproduce the blocking effect by just calling readLine w/o any processing of the data.

First of all I was thinking about a synchronization problem in my code but it seems that file io blocks calls to glVertex3f. Unfortunately, rising the thread priority of the renderthread does not help eighter.

The GarbageCollection may be a point though! Can I alter the gc strategy in some way?

#4

run java.exe with -verbose:gc as an additional argument, to see when the GC occurs, and how long each collection takes.

#5

Good tip!

GC takes about 1-2ms, no particular peaks occured.

I have measured the render time also (just a for-loop sending glVertex3f in selection mode, code below), which has peaks up to 63ms when reading from a file. Usually it is < 10ms.

    // draw faces by hand
    for (int i = 0; i < faces_vertices.length; i++)
    {
        // draw polygon
        gl.glBegin(GL.GL_POLYGON);
        for (int j = 0; j < faces_vertices[i].length; j++)
        {
            // add vertex
            Vector3DVO vec = vertices[faces_vertices[i][j]];
            gl.glVertex3f(vec.x, vec.z, -vec.y);
        }
        gl.glEnd();
    }

It is rendering aprox. 600 faces w/3-4 vertices each face. Drawing in immediate mode can be optimized a lot. But I am thinking that this problem will occure then too (slightly better performance but still blocking when doing file io I think).

#6

Did you try with the NIO classes? RandomAccessFile’s are far smoother to get up vs File’s, I mean they have their own ByteBuffer which does avoid to build extra BufferedStreams.
Plus, did you check for the priority of both Threads loader and render? I always set them to the Max_priority which does improve speed for about the double, because of the GC’ing running at a normal level that can interfer with new Threads instances.
Where RAM data reading can be fail-fast if the heap memory is overflowed, File IO must improve speed to the Bus speed which can vary from 9ms (that is common HDD r/w speeds) to even faster rates, depending on the architecture used for testing.

#7

Maybe you could use FileChannel.