Profiling Xith memory usage

Engines, Libraries and Tools Xith3D Forums
#1

I did some profiling of Xith3d and decided to list some parts of Xith methods and classes that create most work for the garbage collector. I do not know if any of these object creations can be avoided, e.g. by reusing existing objects but I decided to list the methods anyway as I got the report easily while evaluating the profiler.

My test application consisted of 200 objects that are constantly rotated and positioned. The instance count list below consists of Xith objects only. The counts are a result from 2000 view.renderOnce() calls only, so you can double the counts below after each 2000 more frames etc. GC was disabled.

And here is the top instance list:

5719196 double[]
1623184 Object[]
273137 java.util.ArrayList
271142 long[]
271137 com.xith3d.render.StateSortableMap
271137 com.xith3d.render.ColoringShader
271137 com.xith3d.render.ShapeAtom
271137 com.xith3d.render.TextureShader
271137 com.xith3d.render.TransformShader
70943 com.xith3d.render.MaterialShader
64944 float[]
15992 javax.vecmath.Vector3f
8000 com.xith3d.render.RenderingShader
8000 com.xith3d.render.PolygonAttrShader
…

The most interesting part is hefty amount of doubles, 6 million after 2000 frame iterations.
Have no clue what creates these doubles but if I add following code to Xith instead, then renderOnce() (actually getScale method) does no longer create doubles excessively .
com.xith3d.scenegraph.Transform3D
public float getScale() {
//return matrix.getScale(); OLD LINE
return matrix.getScaleCustom(); // new line
}
com.xith3d.datatypes.MatrixExt4f
// new method
public final float getScaleCustom() {
return (float) Math.sqrt((m00 * m00 + m10 * m10 + m20 * m20 + m01
* m01 + m11 * m11 + m21 * m21 + m02 * m02 + m12 * m12 + m22
* m22) / 3.0);
}

And here are the “hotspots” of object creations…

com.xith3d.render.TransformShader
makeTransformShader()
-new TransformShader

com.xith3d.render.RenderAtomBase
-new StateSortableMap
-new ArrayList

com.xith3d.render.StateSortableMap
-new StateSortable array
-new long array

com.xith3d.render.ColoringShader
makeColoringShader()
-new ColoringShader

com.xith3d.render.TextureShader
makeTextureShader
-new TextureShader

com.xith3d.scenegraph.View
getAtom
-new ShapeAtom

com.xith3d.scenegraph.Node
updateBounds
-new Bounds array

Hope this info was any good, Jani!

#2

Yes, it’s helpful. Because it also confirms what I experienced some days ago. Please have a short look at my thread here: the interesting article is the second one named “Question B) jerky movement”.

In that thread Yuri replied:[quote]To minimize problems caused by full GC, we should try to minimize memory allocations inside Xith3D rendering engine. abies already did a lot to reduce memory allocations, but there are still some things to do in that area.
[/quote]
Interesting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these “full GC delays”. Like my recent poll indicates, the Xith3d user base is still very small… as are Java interested game programmers in general. :frowning:

#3

[quote]Yes, it’s helpful. Because it also confirms what I experienced some days ago. Please have a short look at my thread here: the interesting article is the second one named “Question B) jerky movement”.
[/quote]
This is the reason:
TransformGroup.setTransform(Transform3D)
It trashes memory quite a lot. Every transform means lot’s of different tasks for the renderer to do.

It’s extremely easy to see cpu and memory intensive blocks with a profiler like OptimizeIT. You can download 10 day evaluation version from:
http://www.borland.com/products/downloads/download_optimizeit.html

I dont know if all object creation can be reasonably avoided but some optimizations could be done over there. Because now you have to tweak GC a bit in order to avoid
small freezes from happen, e.g. use incgc to avoid freezes but all solutions lower general performance somewhat as long as GC has a lot of work to do.

Note that if you have any tight loops e.g. iterators that go through every visible object and set new coordinates and orientations to your application, make sure you are not unneccessarily creating e.g. Vector3f and Matrix3f objects per each step. This strains GC even more. Just create your transform temporary objects once and re-use them, this helps some.
[/quote]

Put several hundred objects moving to your scene and you are bound to see freezes with standard JVM parameters, GC has a lot to collect…

Summary, Xith might have more important tasks first before optimizing excessive object creation. Then again, maybe not.

PS. Do you have clue what makes those doubles, is it vecmath that has a bug? I got around this by creating my own setScale method.

#4

As for the vecmath, use Kenji Hiranabe version - it is a lot better, as it creates no temporary objects (except one method somewhere, I have corrected it at some point and forgotten now). I have not even started profiling without this change, because data was skewed too much by java3d vecmath garbage. Funny thing is that java3d itself managed to avoid using this heavy methods - it was generating next to none garbage (something like 2 objects per frame for non-trivial scene).

As far as I remember (I have checked it some time ago), one of major garbage generators left in xith3d is ShapeAtom. AFAIK, it is created from scratch for any change in any state of shape3d. I have changed it some time ago to reuse the object and reuse all shaders if they have not changed - this reduced amount of garbage considerably. Unfortunately, I was not able to code it in way that looks elegant (spagetti code is real bad) and I was a bit afraid about possible side effects on state sorting routines, as I’m not fully aware of the way they work.

#5

@Jani: Yes, I always use tempory Transfrom3D() objects which aren’t being destroyed and re-created when a model is being translated/rotated.

@Abies: Ah, so you suggest to use Kenji Hiranabe’s Vecmath. Good hint, I’ll try that.

In a thread here in the forum you quoted an URL to a slightly modified version of this improved Japanese Vecmath. (Inside the Zip there’s a Readme file but the URL to the original Japanese Web site doesn’t work anymore…)

Since you and Yuri say that the slightly modified Japanese Vecmath is good to use with Xith3d: maybe William should replace the Java3d Vecmath on the Xith3d download site with the improved one?

#6

In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I’ll try to prepare version with just bugfixes/missing Tex4f.

#7

[quote]In zip on my page I have also added few methods which are not really needed (I was not aware that opengl has transpose-matrix extension, so I have added methods to vecmath). Tonight I’ll try to prepare version with just bugfixes/missing Tex4f.
[/quote]
Thanks a lot! :slight_smile:

With your current Vecmath version the full GC does occur a little rarer on my example jnlp with 100 rotated objects (mentioned in my first post). However a full GC still occurs every ~7 seconds when all 100 objects are visible.
Well, that’s an improvement compared to the full GC occuring every ~3 seconds with the original J3d Vecmath.

{Edit}: Inspired by the thread named “RFE: SERVER jvm into JRE” I’ve run the same test program with 100 rotating objects with the -server VM switch on Windoze, and voila: when the program runs for 2-3 seconds and is “warm”, the full GC just occurs every ~3 minutes or so, which is a lot better. So it’s not a real problem for my test program anymore. (I’m using Abies’ japanese Vecmath.)

#8

Is there any way that floats could be used instead of doubles, or is Xith intended to be a general purpose scenegraph rather than a games scenegraph?

Cas :slight_smile:

#9

[quote]Is there any way that floats could be used instead of doubles, or is Xith intended to be a general purpose scenegraph rather than a games scenegraph?
[/quote]
From a user’s point of view Xith uses just floats. Internally mostly, too.

{Edit} Xith FAQ #8

[quote]9. Why do none of the methods accept doubles like Java3D did?
Since the underlying graphics hardware only supports floats - a design decision was made to only use floats for all method calls in Xith3D.
[/quote]
PS: However there’s some talk in the forums that today on modern machines the difference between using doubles and floats (all done on the co-processor) doesn’t mean a big performance problem anymore… isn’t it?

#10

There is a noticeable difference if you start to think about more complicated operations - especially square root. Not that java has float sqrt anyway…

BTW, have you noticed that there is sqrt(x^2+y^2) operation hardcoded in 1.5 Math class ? This can probably map directly to some SSE/etc opcodes…

#11

It is available at
http://nwn-j3d.sourceforge.net/xith3d/vecmath.zip

It turned out that after removing my row/column major changes, only difference is one small optimalization in GMatrix and added Tex4x classes.

#12

[quote]It is available at
http://nwn-j3d.sourceforge.net/xith3d/vecmath.zip

It turned out that after removing my row/column major changes, only difference is one small optimalization in GMatrix and added Tex4x classes.
[/quote]
Thanks.

One small problem still: the alternative Vecmath reports an an error message when you try to use the clone() method. It says:
clone() has protected access in java.lang.Object

So when you have got a Point3f object namend thepoint and used
Point3f new = (Point3f) thepoint.clone();
this doesn’t work anymore.

OK, you could use
Point3f new =new Point3f(thepoint);
… but for the sake of full portability I think it would be nice to have the clone method working with the new Vecmath, too. What do you think?

#13

I think it is just a problem of adding Cloneable interface to TupleXY. I’ll do it tonight.

#14

[quote]I think it is just a problem of adding Cloneable interface to TupleXY. I’ll do it tonight.
[/quote]
Yes. Additionally we would have to overwrite the protected clone() method with a public one I think. For example something like this seems to work…:


public abstract class Tuple3f implements Serializable, Cloneable
{
  ...

  /**
   * @return  Binary copy of object
   */
  public Object clone()
  {
    try {
      Object copy = super.clone();
      return copy;
    }
    catch (CloneNotSupportedException ex) {
      System.err.println(ex);
      throw new RuntimeException(ex);
    }
  }
}
#15

Considering the coming Java gaming contest, I’d like to ask again about the state of Xith memory usage.

Does anyone have ideas if Xith’s memory management can be fixed in a month or so? Theres plenty of classes that use the dreaded new clause quite excessively and this strains garbage collector quite a lot. It slows down the performance or causes minor jerking on bigger scenes that have hundreds of objects constantly being transformed.

Again, the “hotspot” that causes excessive object creation is TransformGroup.setTransform(Transform3D), it calls various classes and does several functions, various classes create a lot of new objects and discard old values.

I tried to help a bit by giving a summary of the classes that do excessive object creation (see first mail on this thread), perhaps I might help out some more but Xith internals are new to me.

I assume someone already fixed vecmaths excessive double creation that I stated earlier?

Well, I understand that Xith is under development, anyway this is promising technology have to say!

Cheers, Jani!

#16

With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it…

#17

[quote]Y
Interesting though, that aside the Xith3d developers and helpers (Abies?) just you and me noticed these “full GC delays”. Like my recent poll indicates, the Xith3d user base is still very small… as are Java interested game programmers in general. :frowning:
[/quote]
This perhaps is the cause of the jerkiness I see in almost every one of the Xith demos on the website? About one jerk per second (nb: I don’t have much RAM, only 256 and desktop linux is an evil memory hogger). The silly thing is that apart from that its smooth, it just has a regular (very small) jerk - especially noticeable on the terrain / heightfield demo.

Seeing the simple official demos run poorly on a gefroce2 @ 1ghz is enough to give anyone serious 2nd thoughts I’d think…

#18

[quote]With exception of collision routines, it CAN be corrected withing a month - it is really just few places where considerable amount of garbage is generated. Question is, if somebody will do it…
[/quote]
Can you tell me the people that can affect to this issue in any way? Sure the people are watching these threads also, but I’m considering to send annoying but polite :slight_smile: query for some people and ask experts opinions about this issue (how complex is it, is there plans to fix it in the near future, time estimates).

This problem definately is not on JOGL.

#19

{Edit} Now I see what you mean: small jerks, yes, they’re visible with the demos on my Winblows box, too. Maybe it’s something with their renderloops.
In a “real” application, with timed simulation & render loop, I just see jerks when many objects (100+) with transformations are inside the view. Then every few seconds I see jerks. This is due to a full GC which occurs every few seconds in the Xith transformation code. I think Jani’s memory observation explains it.

Generally these GC related jerks can be examined by tring the following: start the demos or/and your app with:
java -verbose:gc …
However with the Xith demos I can’t get it to work right now.

The Japanese Vecmath patched by Abies improves the memory consumation slightly for me.

However using the server VM solves most of my full GC problems with Xith (the jerks appears every few minutes only). However it isn’t a solution when it comes to deployment via Webstart or similar. So, like Jani, I’m too interested in this being fixed within Xith.

#20

The new 1.5 collectors rock. The -XX:MaxGCPauseMillis=nnn will tune the garbage collector automatically for you. A bit like staring at that graphical profily thing and fiddling with the old tuning parameters in 1.4 until it doesn’t jerk.

Cas :slight_smile: