GlDrawableHelper allocates unecessary Iterator

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GlDrawableHelper allocates unecessary Iterator

Taif
I've recently fallen love with the java allocation instrumenter

http://code.google.com/p/java-allocation-instrumenter/

Garbage collection can be a pain when you're trying to create visuals that run smooth as milk. The solution? Never allocate anything while the "visuals" are running (front load all the allocation).

However, I'm being bugged by the fact that GLCanvas.display calls com.jogamp.opengl.impl.GlDrawableHelper's display method, which creates an AbstractIterator just to iterate an ArrayList.

Of course, I'd fix this myself, but then I wouldn't have the nice signed-applet-certificates that you guys offer.

Are all those iterators really necessary? Perhaps its some really subtle concurrency detail?

Tl;Dr? com.jogamp.opengl.impl.GlDrawableHelper allocates an Iterator every frame - and I'm trying to reduce the allocation footprint of my opengl app.
Reply | Threaded
Open this post in threaded view
|

Re: GlDrawableHelper allocates unecessary Iterator

Michael Bien
if you think you can optimize something just fork the repository on github and do your work.
we can take a look at it later and integrate it if it makes sense (e.g. does not overcomplicate things + does not break something).

contributions are always welcome.

but a single iterator per frame is usually not the problem.

regards,
michael


On 06/22/2010 12:11 AM, Taif [via jogamp] wrote:
I've recently fallen love with the java allocation instrumenter

http://code.google.com/p/java-allocation-instrumenter/

Garbage collection can be a pain when you're trying to create visuals that run smooth as milk. The solution? Never allocate anything while the "visuals" are running (front load all the allocation).

However, I'm being bugged by the fact that GLCanvas.display calls com.jogamp.opengl.impl.GlDrawableHelper's display method, which creates an AbstractIterator just to iterate an ArrayList.

Of course, I'd fix this myself, but then I wouldn't have the nice signed-applet-certificates that you guys offer.

Are all those iterators really necessary? Perhaps its some really subtle concurrency detail?

Tl;Dr? com.jogamp.opengl.impl.GlDrawableHelper allocates an Iterator every frame - and I'm trying to reduce the allocation footprint of my opengl app.


View message @ http://jogamp.762907.n3.nabble.com/GlDrawableHelper-allocates-unecessary-Iterator-tp912785p912785.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

Reply | Threaded
Open this post in threaded view
|

Re: GlDrawableHelper allocates unecessary Iterator

jeff
Taif might be right. anything that is allocated will be GCed once in a while. even if the GC happens rarely, it will happen evenutally and on slow machines this causes a framelag.
Reply | Threaded
Open this post in threaded view
|

Re: GlDrawableHelper allocates unecessary Iterator

Michael Bien
a single FPS counter which displays the FPS String would cause more garbage as an iterator. But in both cases you won't notice it. The objects would die young and wouldn't be evacuated in the young gc phase - which is very fast compared to old generation sweeps.

But again if you have a cool idea how to get rid of it... you know where the repo is :). API Bindings should be GC neutral i fully agree.

regards,

michael


On 06/24/2010 04:00 PM, jeff [via jogamp] wrote:
Taif might be right. anything that is allocated will be GCed once in a while. even if the GC happens rarely, it will happen evenutally and on slow machines this causes a framelag.


View message @ http://jogamp.762907.n3.nabble.com/GlDrawableHelper-allocates-unecessary-Iterator-tp912785p919549.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.