how can we make best benchmarks with joode?
I think we should add an fps counter directly to TestingWorld. And then, where should we show the current fps?
I think we could also log the fps and then print some statistics.
As I see now, we’re printing loads of debug-messages, which decrease speed a lot. Maybe we should wait a bit with the benchmarking until we don’t need these messages anymore?
Oh brilliant Arne! Nice one.
Yeah the printing stuff really slows the whole thing down.
[quote]I think we should add an fps counter directly to TestingWorld. And then, where should we show the current fps?
[/quote]
Yes, I was going on about a proper gaming loop for TestingWorld a while back. If we did the looping properly we could get the FPS out of the timing.
[quote]I find the Geoms in my OctTree by their bounds. So, if I change the bounds, I won’t be able to find my Geom anymore. Luckily the bounds only get recomputed shortly before I test for collisions, so after removing the Geom. But if the bounds also get updated somewhere else, this bug would mean a memory leak (I would deposit references in my tree, without ever finding them to delete again)
[/quote]
OK well remember that one. We will come back to it…
Yes, I was going on about a proper gaming loop for TestingWorld a while back. If we did the looping properly we could get the FPS out of the timing.
[/quote]
Why do we need a proper game loop to calculate the fps? I believe step() in TestingWorld gets executed exactly once per frame, right? So we could simply save the old time when it got executed in a global var. in TestingWorld and compute the time difference, when we step() is called again.
Then we’ll simply have to add a method s.th. like getFps() to TestingWorld and then the gaming loop can be anywhere.
Ohh and we would have to remove that Thread.sleep(), we use now to control the speed in for example SphereCollisionTest.
Give me an OK and it’s there 
OK.
But I read System.timeMillis() wasn’t precise, so beware !
we’re 1.5 remember? So System.nanos is the way to go!
Yeah that would be fine in step().
Sorry I am not about much at the moment. It is the end of term and I have numerous peices of work in 
I will be back in full swing in about a month.
mmh I think we’ve got a problem…
At the beginning we’ve got an fps of around 0.3 (because of all those collisions) this, because of the small fps leads to a big step -> many new collisions -> a new low fps, grater forces (because of the grater intersectionDepth) so the beginning progresses now faster than before (nah ok … dunno if this is a problem)
Here’s the fps sequence:
0.29836214 3.9929085 18.948008 11.978774 6.87271 9.793552 9.774406 16.952888 12.979427 16.268627 49.73145 28.118322 47.127575 47.094284 18.933657 17.28967 33.475044 26.359491 51.816154 50.175613 46.715874 32.58709 60.31363 21.247663 30.44696 50.208366 53.850296 24.87624 30.246204 9.998401 27.145145 94.08223 97.05911 86.79802 32.187458 121.99585 104.54783 122.219505 101.32739 44.984257 36.39805 106.59844 37.20515 106.64391 119.70313 101.90563 108.049706 50.188206 94.24182 127.40476 107.13521 123.517784 33.2823 125.32899 109.48106 128.15584 91.911766 52.134926 104.635345 85.20791 106.53031 125.26619 34.568584 91.7347 74.15097 136.64935 53.376034 133.70772 111.50758 133.15579 137.64626 115.43346 42.468254 94.51796 136.29549 135.483 110.509445 69.032166 108.68384 138.10248 114.10315 127.975426 80.899605 55.23336 104.59157 113.48161 138.23611 111.91942 64.12723 129.65125 116.57729 135.318 95.46539 136.76149 50.0025 109.18223 103.34849 112.29646 135.88803 59.44243
Average: 77.0327
OK.
I’ve found a good quick algorithm for logging the fps history. It consumes only a constant amount on memory and adding of new frames runs in true constant time.
I’ve also coded a graphical output of it.
I’ve added a screenshot. I also print an average fps and the number of frames on the console.
If you want that output when quitting your application, you’ll simply have to call FPSCounter.exit instead of System.exit.
I’ll do some commenting and then I will commit it.
EDIT: mmh I’ve just seen, that the measurement on the fps axis is wrong - I get MUCH higher fps!
Ok … a thing to fix
Nice !
You could do that as an external mini-profiler that every program could call ! And add some features and make a java.net project for that and make a website and provide IRC support and… ok i’m joking but the external lib idea is good IMHO.
yeah I kinda thought about that, too, but it’s only one class.
And it’s actually universable useable - it hasn’t got anything JOODE specific
Ok FPSCounter finished ;D 8)
Check it out on the cvs. And please care to read my javadoc - I explain my algorithm there.
*It would be too much to post it here again
what fps-curves do you get?
I’ve changed SphereCollisionTest and OctTreeSpaceTest to use my new fps measuring method.
All other tests using TestingWorld will also use it, but they will only log and use the current fps for step sizes, but never print statistics.
Ohh and I changed my X-Axis to time instead of the frames. I think it’s better this way, because then you can see analogies to the things that happened on the scene better. (I bet your fps isn’t that low, that you actually can count the frames he?)
Ooooone, twoooooo, threeeeee, ^^ no fps isn’t that low, hehe, but pretty irregular, see the curve I get for OctTreeSpaceTest :
yeah my first screenshot isn’t that irregular, because I have set it there not to save so many values. It looks even more irregular, if I show even more frames. (Change that constant in FPSCounter, if you want to play around with that)
I also get pretty low fps on my first frames. In both, OctTreeSpaceTest and SphereCollissionTest.
We should make a testcase, where it starts with a clean start - not something, where many Geoms intersect.