>> Andrew Moulden wrote:
>> My profiling of running J3D apps suggest there is a tremendous amount of
>> object creation (and hence gc-related destruction) which could probably
>> be substantially reduced if we could see the code. This is especially
>> true in the area of behaviours which I assume rely more on Java
>> implementations than being channelled through to underlying native
>> implementations. As I'm sure just about everyone knows, creating objects
>> in Java is hideously expensive.
>>
>Roberto Speranza wrote in reply:
>The Java3D team is aware of this. Most of the API calls currently copies
>objects you supply to it and work with the copies. If you look at the
>latest proposed API changes for Java 3D 1.2, you will notice the >addition of
>many methods that can be used to pass your objects by reference .ie. they
>won't copy your objects, they will just use them. This should get rid of
>the majority of the object creation overhead.
Okay, I'll profile release 1.2 when it comes out and see what difference
the API changes have made.
>>Andrew Moulden wrote:
>> As one of many examples take this code snippet from the
>> TCBSplinePathInterpolator class in the com.sun.j3d.utils package
>> (comments are the code author's):
>>
>> --------------START EXAMPLE---------------
>> public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
>>
>> (stuff deleted)
>>
>> // Make space for a leading and trailing key frame in addition to
>> // the keys passed in
>> keyFrames = new TCBKeyFrame[keysLength+2];
>> keyFrames[0] = new TCBKeyFrame();
>> keyFrames[0] = keys[0];
>> for (int i = 1; i < keysLength+1; i++) {
>> keyFrames[i] = new TCBKeyFrame();
>> keyFrames[i] = keys[i-1];
>> }
>> keyFrames[keysLength+1] = new TCBKeyFrame();
>> keyFrames[keysLength+1] = keys[keysLength-1];
>> ---------------END EXAMPLE------------------
>>
>> Now if I'd read this in anything other than a Sun source document I'd
>> have said that the programmer had a fundamental misunderstanding of >how
>> the Java language works, but obviously this is just an oversight in this
>> particular case. Nevertheless it does mean that completely redundant
>> objects are being created by this behaviour class which immediately
>> entail time-consuming garbage collection.
>
>Roberto Speranza wrote in reply:
>Actually, this is another case of copying supplied objects as mentioned
>above. The only weird thing I see there isn't that they just didn't put
>everything in the loop but that is probably an optimization to deal with
>empty keyframe lists.
Actually, this is another case of someone replying to a message when he
has not taken time to digest what is being discussed. With all due
respect, I recommend you read the example I gave again V_E_R_Y
S_L_O_W_L_Y and then make your observations.
>>Andrew Moulden wrote:
>> Also in the same class we have the computePathInterpolation() method
>> which is called *every frame*:
>>
>> --------------START EXAMPLE---------------
>> protected void computePathInterpolation() {
>> float value = (this.getAlpha()).value();
>>
>> // skip knots till we find the two we fall between
>> int i = 1;
>> while ((value > keyFrames[i].knot) && (i<keysLength-2)) {
>> i++;
>> }
>> (rest of method deleted)
>> ---------------END EXAMPLE------------------
>>
>> There are a number of comments that can be made about the while loop,
>> but basically: 1) the (i<keysLength-2) can easily be made redundant and
>> 2) there are very fast alternative methods to finding which keyFrame
>> knot the alpha value falls between. Counting up from 1 is about as slow
>> as you can get.
>
>>Roberto Speranza wrote in reply:
>Aside from using a hashtable of some kind (which will take up much more
>memory), I think the way they did it is probably the best method for trading
>off performance versus memory usage.
...in which case you're completely wrong. Look, I'm trying to raise a
serious point about performance here. We are talking about a 3D API
which many of us would like to see become a world-leading development
platform.
If you're writing stuff for Java servlets then you can write the
crappiest code imaginable and still be 10 times faster than any CGI
script. But this is realtime 3D - the most demanding programming domain
around except maybe for massively transactional servers.
When you have a method in J3D that is called *every frame* it is in my
view a requisite on the part of the programmer that the routines be
optimized to squeeze the very last drop of performance out of the code
implementation. I have spent and hours and hours optimizing server and
parser code for performance, and your comment that 'I think the way they
did it is probably the best method for trading off performance versus
memory usage' is extremely dangerous because it may lead folk to believe
that they *have* got it just about right.
On what basis do you make this statement? Can you supply some test code
proving it? No, you can't.
Go look at the Swing source from 8 months ago. Now look at the present
source. Notice any difference? For one thing critical loops now
decrement rather than increment due to faster underlying processor
instruction sets. If this is deemed worthwhile in GUI code which is
hardly time-critical, don't you think it might be worth considering in
realtime simulation systems? Nonetheless, even this optimization would
be less than appropriate for the loop I cited (and it can be made faster
without using any extra memory. Hashtables? you must be kidding...).
I don't know whether I'm breaking any conventions here and being too
provocative, but I don't see any point in everyone pretending Java3D is
perfect. I for one am more than happy with how things are progressing,
and I have every respect for the J3D team who have forgotten more about
3D graphics than I will ever know. But as always good isn't good enough.
Only best will do.
Andrew Moulden
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
