Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (616)
Games in Android Showcase (173)
games submitted by our members
Games in WIP (659)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  File IO blocks rendering  (Read 2337 times)
0 Members and 1 Guest are viewing this topic.
Offline Mezzerman

Junior Newbie

« Posted 2007-08-10 10:37:02 »


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!
Offline Riven
« League of Dukes »

« JGO Overlord »

Medals: 1040
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #1 - Posted 2007-08-10 10:56:28 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Mezzerman

Junior Newbie

« Reply #2 - Posted 2007-08-10 11:16:58 »

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?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »

Medals: 1040
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #3 - Posted 2007-08-10 11:39:48 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Mezzerman

Junior Newbie

« Reply #4 - Posted 2007-08-10 12:32:56 »

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
            for (int j = 0; j < faces_vertices.length; j++)
                // add vertex
                Vector3DVO vec = vertices[faces_vertices[j]];
                gl.glVertex3f(vec.x, vec.z, -vec.y);

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).
Offline broumbroum

Junior Devvie

« Reply #5 - Posted 2007-08-10 23:12:22 »

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.

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @
on /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline gouessej
« Reply #6 - Posted 2007-08-28 18:29:06 »

Maybe you could use FileChannel.

Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Coldstream24 (19 views)
2015-09-03 00:41:28

Andrew_3ds (31 views)
2015-09-01 19:08:10

afikri (20 views)
2015-08-31 09:30:22

afikri (27 views)
2015-08-31 09:30:07

afikri (15 views)
2015-08-31 09:27:24

afikri (17 views)
2015-08-31 09:26:40

Roquen (32 views)
2015-08-29 11:30:54

GamerC4 (41 views)
2015-08-22 20:38:50

GamerC4 (37 views)
2015-08-22 20:37:18

GamerC4 (43 views)
2015-08-22 20:37:01
HotSpot Options
by Roquen
2015-08-29 11:33:11

Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!