I'm really glad newless clewbies is back... Here is what I want to do;

Make a static utility class with static methods that will operate on objects (think Math.cos() for example) for my 3d software renderer. For example functions that are called many times per frame such as:

Polygon3D utility.clipToFrustrum(Polygon3D poly);

So I'm curious if this completely wrong, non oop, non java approach would indeed be faster than the alternative correct approach;

newpoly = poly.clipToFrusrum();

(please don't flame me for not using java2d tranforms and clipping stuff! This is a learning exercise!)

It isn't wrong.. but it might not be the best technique for your situation. Certainly the various Math methods make perfect sense as static methods.. it would be dumb for example to construct a Double object just so you could call cos() on it...

You likely have a case where some static utility mehtods make sense, but in your one example.. what defines the frustum? Should you have a Frustum object with a clipTo(Polygon3D) method?

You have near and far clipping planes and field of view... either they will need to be arguments to the clipToFrustum method, or you will need a single static frustum defined in the class, make the clip method part of the Polygon3D object, in which case it could take a Frustum argument, or there could be a single Frustum defined as a class variable, or do what I mentioned above and have the clipTo method an instance method of a Frustum class.

Lots of options and it isn't always a matter of getting right or wrong.. you have to imagine what will be best for the overall design.

Look at some of the cases where Sun has used static methods (SwingUtilities, Math, etc..) and try to reason why they wre done as static methods. you should likely have the same kind of reasons for your Polygon3Dutility methods

*edit*P.S. Speed should not be a concern at all when choosing to implement something as static vs. instance methods. (optimization generally comes later - unless you know from experience and have are confident that one choice will definately be TOO slow.)

To answer to the subject's question: No, static methods aren't faster. The Hotspot VM (Sun's Java virtual machine) should be clever enough to optimize (compile, inline, de-virtualize) methods automatically based on their usage.

And don't fool yourself using micro-benchmarks like calling one method in a tight loop a million times or so. Such kind of benchmark isn't generally representative and gives the VM no chance to collect usage data for its optimisation.

And don't fool yourself using micro-benchmarks like calling one method in a tight loop a million times or so.

Yeah, but thats kind of what a rendering loop is though; only with a few more functions/methods. In my mode7 applet the fps does increase by about 2-4 fps after the first few seconds (this is using a regular member drawing method of a normal class) I assumed that was due to the vm optimizing. Hmm, guess I'll have to try and see.

In a precompie\led language like C++, definign a method as static tells the compiler it can be sure that call points calling the method are monomorphic (their destination is a single dterminable address) and thus it allwos for better inlining.

Java JITs however don't need this clue. Because they have run-time info available they can (and hotspot does) determine if a call point is monomoprhic based on the currently loaded classes adn do the same sort of inlining. Thus declaring somethign static has no advantage over simply not using it in an overloaded manner.

(If a late load changes the call point to be truely polymorphic, with multiple possible destinations, the opimizations are backed out automatically by the VM.)

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

JIT certainly needs this clue. While it can manage to inline code without it, it's job is a lot easier if it knows that given call is private/static/final. Generated code will be a bit better (no need for fallback clauses), jit time is smaller.

This is certainly nothing to worry about in J2EE apps or even desktop J2SE apps, but for game apps, it _might_ be a difference. Certainly static/private/final methods are not slower - so you cannot lose by using them.

Any simple benchmark will not give you the true answer - for 1-2 class code, jit can do any optimalization it wants. For thousand classes, there is only limited amount of magic that can be done in real time and any hints you can give to jit certainly can help.

This may be true. But it is still advisable to use 'static final' only for methods that truly SHOULD be static and final. Then if performance is an issue, profile and tweak. If making something static final improves the measured performance at that stage, go for it. Don't design that way up-front unless you know you have to. It just ties your hands from doing other kinds of refactoring and algorithms too early in the process.

I'm in no way proposing using final/static everywhere, just for sake of possible speed - I was adressing statement that it is totally not needed for jit.

As for final, it should be probably used only for security/design reasons (you really do not want to allow subclassing of given class/method). For other things, I try to stick to following guidelines, which IMHO are quite acceptable from both performance and design side:

1) If something does not touch state of object, make it static. While having such functions (method is not really good name) is non-OO, making it a member method will not make it any more OO. For me, main benefit is reuse (don't have to create proxy object just to call it) and clarity (I'm sure that static method do not modify state of object).

2) If you need helper method for other methods working on object, make it private. Again, main benefit is not cluttering public namespace with methods which really have meaning only inside class body, possibly leaving object in half-cooked state.

3) Use final only for security and to protect fellow programmers from overriding targeting mechanism of gun - to protect innocent feet. Security reasons are obvious (vide String), protection - only in most dangerous cases, especially if there is some kind of voodoo magic going behind.

1) and 2) have a nice effect of being performance-friendly - both static and private methods can be inlined with ease. While this pleases my clock-counting part of personality, main reasons are ones stated above - clarity in most cases

I wasn't trying to argue or anything - I just wanted to make it clear for the newbies.

To add to your list, another point for not using static is if you might need to override the method, even if it doesn't touch the object, it might want to do things differently when called in a different context - e.g. called from another method that can not be static. It's less common, but it can happen.. specially with singletons.

I have done a simple benchmark and static methods are at least umpteen percent faster than instance ones - for simplest case, where Hotspot _for sure_ can inline everything.

Indeed, I was not able to see a difference between public, private and public final instance methods - so it seems that for this few lines benchmark, Hotspot is smart enough to devirtualize a call, but not smart enough to make it as fast as static method.

In this case, umpteen means 30% faster, or 45% slower. This is a result for client jvm 1.4.2, server jvm is a lot better (around 2500ms, with 50-60ms penalty for instance method, so this means around 2% difference). But let's focus on client version

difference is about 7-8 percent and the server VM is slightly slower here ( to be honest, this is not the only case where the client outperforms the server on my machine although the difference is very small in this case)

In any way, the difference between static and instance calls seems to be too small to care much, really (although it would of course be nice if there was no difference at all).

In any way, the difference between static and instance calls seems to be too small to care much, really .

Too small on your computer, not on my or overnhet.

I'm in no way advocating using static methods for speed here. I'm just fighting a statement that Hotspot can optimize such things to no difference - it can be clearly seen that it cannot. Fact that some processors are smart enough to optimize slower case or stupid enough to not optimize faster route does not change the fact that one some processors difference is noticeable.

Yes, and I had obtained such similar results too withi/sadd(1,2); So, would this breakdown be any reasonable ?Overhead simply due to declaring a function instance/static -looks like there is none. Any extra optimization that theJVM would make use of if the function does a little morenon-trivial work. I don't want to get into areas where I'm not an expert

Edit: Of course, hard to quantify what would happen in a realfull fledged application when the JVM would be highly loaded - standard disclaimer !

It gives 19828ms for instance, 5750ms for static (this is not comparable to my previous results, as I use different computer now).

4x difference is even better to show the problem, so maybe we can start to talk about 'corrected' benchmark now

I have done printout on purpose - without it, method is too trivial to optimize. Even with printout, it is possible to compute statically, but I hope that thanks to the overflow it is not something that normal compiler will try to do.

This benchmark is really trivial, to show that even in simpliest cases Hotspot shows difference between such calls. With more complicated ones, it can get only worse.

As for making loop shorter, please be sure to use both v and i inside it. If you don't modify v, it is possible to just run last iteration of loop. If you don't use i, all iterations give same result. So v = iadd(v,i) is absolutely bare minimum for anything reasonable - but you need to keep adding instruction long enough to server Hotspot stop optimizing it completly (we are not testing Hotspot in general, we are testing difference between static and instance method invocation speed).

(1) I removed the prints in the middle of the tests. No no no bad bad bad. IO blocks in the system and will dominate your results and destroy their meaning.

(2) I put ANOTHER "non-static" test AFTER the static test. This illustrates exactly what I thought was going on, your test was order dependant because you weren't fully warming up the VM prior to starting your tests.

Results on my mac show these calls ARE identical, within a pretty meaningless margin of error:

results:

1 2 3

Instancemethod 10366msStaticmethod 9154msInstancemethod 9142ms

Gee, based on your benchmark static methods are SLOWER!

(Just kidding, its obviously noise or the tail-end of the wram-up issue effecting the second test.)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org