I was initially going to reply directly to the author but since he decided
to make some assumptions about my background, I feel the need to clear up
any misconceptions this may give about me and about my programming
background to the rest of the people on this list. The reason for this is
that I occasionally try to respond to people's questions and I feel the
previous response in this thread may cast doubt on my credentials to answer
3D-related questions. If any one wishes to skip this message, please do so.
Any further replies I have to make along these lines will be directly to the
author.
----- Original Message -----
From: Andrew Moulden <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: September 3, 1999 6:10 PM
Subject: Re: [JAVA3D] Will Java3D source ever be published?
> >> 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.
>
You have every right to do so.
> >>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.
>
I read it over slowly enough, thanks. The code is duplicating TCBKeyFrame
objects. From one point of view, I agree it is wasteful. But they chose to
make copies of objects in the majority of API calls for reasons they have
already spelled out. It is done. They are proposing to address it in the
manner outlined in the Java 3D 1.2 API spec. If you don't like this class's
implementation, don't use it. Write your own class that does it the way you
like. The utils package is not part of the Java 3D API. It is a
convenience library supplied by Sun for the benefit of programmers to help
them develop applications quickly. If you would like them to change it,
send in an official request to change it to the team's e-mail address and I
am sure they will consider it.
> >>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.
>
This sounds like you are insinuating that I write crappy Java code and I
don't notice it because I only program servlets. I have been writing Java
code since the first versions were released and I would like to think that I
have learned a few tricks over the years about optimizing my Java code
especially since I have been programming computers for the last eighteen
years and have done so professionally for the last eight years. Most of my
Java code of late is for Swing apps and the programs I have worked on to
date work to save and plot real-time data streams over TCP/IP coming out of
embedded controllers that are sampling multiple medical signals at rates up
to 500 Hz. Another app is used to examine collected medical data from the
same device packaged in Jar files that are as large as 192 Mb in size where
I have to be able to plot representative data on screen from an expanded
channel file that can be a few Mbs in size as fast as possible. In both
cases, my initial implementations may have been slow but I was always able
to optimize the code for more speed until it was acceptable to the client
(in this case, the U.S. Navy and the Department of National Defence in
Canada). Therefore, I can identify inefficient code and I know how to
rewrite it so that it is faster. My internet business is another business I
run concurrently with my software consulting business and in that business,
I do code a lot of servlets and no, they are not time-critical (usually).
> 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.
>
For God's sake, lighten up. I realize that there are other optimizations
possible that could, for example, store the last index selected and start
searching from there the next time through or that there may be completely
different ways to navigate the key frames that is faster. However, I am
sure that optimizing non-core code is not at the top of the priority list at
this time. Fixing the core API is.
> On what basis do you make this statement? Can you supply some test code
> proving it? No, you can't.
>
I am basing the statement on gut instinct obtained from coding 3D modellers
and renderers with my own APIs on the Amiga platform years ago in C and C++.
I was younger then and I used a similar loop in my own code for a similar
function. I didn't finish that software so I suppose further optimization
would be possible if I had continued to work on it but I guess I'll have to
wait until I begin the rewrite of the code in Java ...
> 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...).
GUI code is hardly time critical, really? If it wasn't an issue, why were
so many people complaining about the speed that they needed to speed it up
in the first place. As for Swing, Swing is quite a bit more mature than
Java3D by about a year or two. Remember, a lot of Swing code was part of
Netscape's high end GUI package initially. Java3D will improve with time.
It seems most people are impatient and maybe feel that the team isn't
listening because progress is slow. Give the guys a break. They are going
as fast as they can.
As for hashtables, they are just a form of lookup table and lookup tables
often provide the quickest responses for finding data you need. Ask any
hardware guy. They use them all the time.
>
> 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
>
I don't pretend that the Java 3D API is perfect. It is a work in progress.
Deadlines always force the release of code earlier than it should be due to
market pressures and customer demand. It's the reality of this business.
I personally haven't had the time to delve into the code too deeply myself
unless I was using a class and needed to see how it was implemented. I am
slowly ramping up on my experience with the Java3D API and may eventually
come to the same conclusions you have once I see more of the code.
Next time, however, please don't attack me or my background unless you know
me better and you do it in private so that you don't force me to defend
myself on this list again. You'll notice that I didn't attack you back in
the reply except maybe the lighten up comment (Sorry). If I misinterpreted
your response as an attack, please cappt my apologies.
>
===========================================================================
> 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".
Again, I apologize to other members of this list for taking up bandwidth on
this topic but I felt the need to defend myself publicly.
Thanks.
Roberto Speranza
President, Dot Internet Solutions Inc.
mailto:[EMAIL PROTECTED]
http://www.dotinc.net/
===========================================================================
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".
