hello,
i have to ask about fps. It show whole java + opengl executing per frame as i good know.
and my question: how to easly check separately time of executing opengl(without my java code - but with jogl ofc)?
i just need to be sure i don’t need optimize java code
time of executing (main loop + AppStates) updating: 0.0040 second - its very good
but i have 20 fps with common scene(lighting terrain and some low poly models). i know i have weak Hardware, but i just want be sure it’s not my code fail
and sorry for my stupidity 
You check performance with a profiler. you can use the netbeans profiler if you use jMP. it can be added from plugin list. It is easy to use also.
1 Like
ahh yes, thank you. its very illegible for me at the moment, but some practise and i should be able to see issues i hope
There is a tutorial at: http://profiler.netbeans.org/.
EDIT: Hmm hasn’t been updated since NB 6.5 it seems? Still works i suppose.
1 Like
@oxplay2 said:
ahh yes, thank you. its very illegible for me at the moment, but some practise and i should be able to see issues :) i hope
Its not very hard to do simple profiling tho. Once you learn the basic stuff in that tutorial, like setting roots (what packages to profile). it is in fact very easy. Look at their CPU monitor on the page. That's how it looks (the one with the red bars).
The CPU monitor monitors total execution time of a method. You can for example just profile your own packages and see which methods are in the top. Those are the ones to focus on. Those should be optimized into bottomless hell imo, manual inlining, math stuff etc.
Speaking of inlining - something i learned is to always avoid FastMath stuff in time-critical methods and loops (and in general tbh). It's often just an additional nested method. No benefits. There's also a significant delay in most methods. I noticed for instance on an intel-i3 the FastMath.sqrt (and others) was 3-4 times slower then Math.sqrt. I got data to back this up if you like to see. Run that stuff 10000000 times and it adds up.
Also there is the heap and thread stuff you can check, which is great. You can see and monitor how large the heap is etc, to check for "memory leaks" etc.
Remember profiling can be miss-guiding tho because speed (even relative) does depend on your jvm version and architecture to some degree. But making math stuff better and manual inlining is usually always good. At least clean up the most obvious weird stuff.
EDIT: Also I think don't do to much before you know a class/method is somewhat stable. You'd spend a lot of time optimizing code that will never be used otherwise.
1 Like
Really, all the stuff done in java is requiring tiny amounts of processing power compared to what happens when the scene gets rendered by OpenGL. And FastMath is constantly used and working fast, as the name suggests, especially relatively across platforms. If you think your application works better with Math.sqrt I suggest just changing the FastMath method in your app.
1 Like
Thank you @androlo
i will look into tutorial. i will propably gain new addiction 
and i dont known that FastMath can be slower on some platforms. this gives much food for thought.
and yes, as i managed to observe Java computing costs is tiny comparing to OpenGl computing costs, like normen said.
Thank you again
Note that if you get lost in these details too soon you will never get anywhere in coding your application, these things are best taken care of when theres actually an application to test the results of changes. Artificial tests rarely show what the actual bottlenecks in an application will be.
@androlo said:
Speaking of inlining - something i learned is to always avoid FastMath stuff in time-critical methods and loops (and in general tbh). It's often just an additional nested method. No benefits. There's also a significant delay in most methods. I noticed for instance on an intel-i3 the FastMath.sqrt (and others) was 3-4 times slower then Math.sqrt. I got data to back this up if you like to see. Run that stuff 10000000 times and it adds up.
I strongly have my doubts. sqrt is expensive. FastMath is only calling Math.sqrt's method with some double->float casts (which you'd have to do anyway). Hotspot should inline those method calls in a few seconds. And in any case, the expense of the sqrt call will way larger than the method call overhead. So I think there is something wrong with your test methodology.
Edit: because 3-4 times slower (300%-400% of the normal run?) is not right.
Yes it really should not matter which one you use.
I’ve been doing the tests a few times today just to make sure, and i get the same results i got last time. I found this out when I was first trying the random generator in grass/trees. Both the first time and this time I get varying results; sometimes insignificant difference, sometimes larger, but consistently in the same direction, and the ratios does not change if i switch the methods. The difference tho is I noticed something I missed last time, and can now increase/reduce the delays. Almost to the point where I can predict what the ratio will be.
It is very interesting.
Well, I cannot see your test so I cannot suggest what may be wrong with it.
I have done independent testing, there is no timing difference between FastMath.sqrt and Math.sqrt. Your benchmark is flawed somehow.
Edit: in case it matters, this is desktop Java I’m talking about… not android.
Haha yes. I think I know what causes the weirdness - the sqrt method is lighting fast now. Really, really fast. The stuff I’m witnessing are all on the micro level. Slower methods like sine/cosine behaves as you’d expect (at least if taken outside the “fast range”). This used to be a large issue.
This is great. You always learn new stuff when profiling, one way or another.
It have also been able to determine the following: hotspot rules.
In my test, FastMath.sqrt and Math.sqrt are no different in speed. Sometimes one sqrt’s run (of 25 million sqrts) is a few nanoseconds faster and sometimes the other is. It doesn’t even take very long for the JVM to optimize to this warmed up state.
What are you taking the sqrt of? I run a loop over 1 million randomly generated values between 0 and 1 million and I run this loop 25 times. In the first run the times are close, by the second through fifth run they swap back and forth in performance.
I can provide the code if you are curious.
No thank you pspeed there’s no need. I’m sorry for weirding this thread up and i don’t want to derail it further. The idea that sqrt is slow was so deeply ingrained it blocked me from even considering anything else. Since FastMath calls Math calls StrictMath native method i figured maybe it could cause some stalling on some systems, or some jvm versions chokes up in some weird way, or whatever. You’re talking to someone that did most his programming when stuff were crap, then took 10 years off. Didn’t bother doing extra tests just stopped using it. You know. Got up. Went to the bathroom. Made a sandwich. Watched some tv.
Again, sorry for polluting the thread with this nonsense.