 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007Static methods slower?
Hello, I'm having a discussion with my colleagues (and boss) over the use of static methods in a class. My colleagues say that static methods should be avoided whenever is possible, because their use slows down the application. For me, this sounds absurd - I believe that static methods should be used whenever they're necessary. However, I wasn't able to find any reliable documents on that. Does anyone knows of a reliable source (like Sun) that discusses that? Thank you in advance, André > My colleagues say that static methods should be avoided whenever is > possible, because their use slows down the application. He probably had a few beers too many when he learned about "static" and "sychronized", and got the two mixed up. Static methods are faster than instance (virtual) methods by virtue of not being virtual. > He probably had a few beers too many when he learned about "static" > and "sychronized", and got the two mixed up. > > Static methods are faster than instance (virtual) methods by virtue of > not being virtual. Thank you. This is obvious to me, but there is any reliable (like Sun's) documentation telling that? André >> He probably had a few beers too many when he learned about "static" >> and "sychronized", and got the two mixed up. [quoted text clipped - 4 lines] > Thank you. This is obvious to me, but there is any reliable (like > Sun's) documentation telling that? Whenever anyone asks "is A faster than B" my immediate thought is - why not write a test program and measure it? Just a thought. > > He probably had a few beers too many when he learned about "static" > > and "sychronized", and got the two mixed up. [quoted text clipped - 6 lines] > > André Actually, I would do the opposite. Ask him to produce the documentation that describes static methods to be slower. There is likely no documentation anywhere describing the relative (or absolute) speeds of static vs virtual methods in java. Whether or not static methods are faster should not be used in design considerations anyway. You should rarely micro-optimize, and you should never optimize at all until you've gotten a working project and have profiled it. 1. Implement a user story 2. Test 3. Refactor (improve design, remove duplication, etc...) 4. Test again. 5. Go to step 1 6. If product is fast enough, finish 7. Profile 8. Optimize 9. Test 10. Refactor 11. Test again. 12. Go to step 6 I've never heard that static methods are slower. And if a method isn't static then surely you have the overhead of instantiating an object before you can call it? Static *variables* are manipulated in heap memory, and are therefore slower than local and method argument variables. Maybe this is the confusion? Graham > > He probably had a few beers too many when he learned about "static" > > and "sychronized", and got the two mixed up. [quoted text clipped - 6 lines] > > André That could be, although it falls into the same category as "synchronization is too expensive". If the design requires it, then you need it, expensive or not. You must use the appropriate language features to get the job done. > That could be, although it falls into the same category as "synchronization > is too expensive". If the design requires it, then you need it, expensive or > not. > > You must use the appropriate language features to get the job done. This is the main point. People might argue that a tank is slower than a Formula One car, but which one is more appropriate for use in warfare? If speed is not relevant, arguments based on speed are specious. Someone who kills a good design based on specious arguments is a saboteur. Saboteurs in a project should be fired. Tell your coworkers that their arguments are really justifications for termination of their employment. - Lew <andre.nho@gmail.com> wrote: >I'm having a discussion with my colleagues (and boss) over the use of >static methods in a class. >My colleagues say that static methods should be avoided whenever is >possible, because their use slows down the application. They're idiots, on two fronts. They're just wrong, which is bad enough. And if they advocate giving up clarity of design even if it did give slightly better performance, they're simply bad programmers. Teach them, or find better employment. Static methods may be a hair faster than instance methods. There's one less parameter to pass, and dispatch can be done directly rather than resolving virtual methods that could be overridden. In reality, most modern VMs optimize call performance so well that you'll be hard-pressed to measure any difference big enough to affect any real program. Even so, the coding contortions you'll go through to avoid one or the other is likely to cost far more than any savings you do get. >For me, this sounds absurd - I believe that static methods should be >used whenever they're necessary. Agreed. They can be overused, and in many cases it's fine advice to avoid them because it breaks encapsulation and makes your object model unclear. But when they're appropriate, they're very useful. >However, I wasn't able to find any >reliable documents on that. Does anyone knows of a reliable source >(like Sun) that discusses that? Any performance difference is too small for anyone to document as good or bad practice. A good habit to get into when someone says "X performs badly" is to ask "how badly?". And then to actually measure it if you don't believe them. -- Mark Rafn dagon@dagon.net <http://www.dagon.net/> > Any performance difference is too small for anyone to document as good or bad > practice. A good habit to get into when someone says "X performs badly" is to > ask "how badly?". And then to actually measure it if you don't believe them. Or better yet ask them, "How badly? Why? Where's the proof?" Hello, I'm having a discussion with my colleagues (and boss) over the use of static methods in a class. My colleagues say that static methods should be avoided whenever is possible, because their use slows down the application. For me, this sounds absurd - I believe that static methods should be used whenever they're necessary. However, I wasn't able to find any reliable documents on that. Does anyone knows of a reliable source (like Sun) that discusses that? The Boss may not always be right but The Boss IS the Boss Just tell the boss how dumb all those folks are that know all about Java, since that are saying just the opposite. >My colleagues say that static methods should be avoided whenever is >possible, because their use slows down the application. >For me, this sounds absurd - I believe that static methods should be >used whenever they're necessary. The difference between »avoid whenever possible« and »use (only) when necessary« might be considered to be somewhat subtle. >However, I wasn't able to find any reliable documents on that. >Does anyone knows of a reliable source (like Sun) that >discusses that? Look how Sun is doing it in the Java SE class library. All methods of java.lang.Math are static. There are many other classes with static methods. > >My colleagues say that static methods should be avoided whenever is > >possible, because their use slows down the application. [quoted text clipped - 18 lines] > All methods of java.lang.Math are static. > There are many other classes with static methods. Hi, I don't think, though, that java.lang.Math could be considered as a good designed class. The only reason beside the historical ones for making all the methods static there is, I think, the fact that people might be more accustomed to invoking the methods as mathematical functions rather than using message sending instructions. On behalf of the original question, I'd say that in the case that the object is however instantiated, the gain in speed from making a method static is negligible (as somebody mentioned before by the fact of not being virtual). The gain might be more substantial if the actual object is never instantiated (creating object is time consuming in Java). However, I don't think that in either of the cases the speed should be considered as a criteria for making the decision. F. Berisha > The gain might be more substantial if the actual object > is never instantiated (creating object is time consuming in Java). > However, I don't think that in either of the cases the speed should be > considered as a criteria for making the decision. IIRC Sun explicitely put PODTs in Java just because of the speed issue (object creation was even more expensive in the old days). Others have pointed out the drawback of this hybrid approach, namely the paper " Primitive Types Considered Harmful". In other words, speed probably *was* a valid criterion in the past and now we have to live with the legacy. Kind regards robert Faton Berisha wrote: >> The gain might be more substantial if the actual object >> is never instantiated (creating object is time consuming in Java). Not very time consuming at all - mostly just bumping a pointer up. >> However, I don't think that in either of the cases the speed should be >> considered as a criteria [sic] for making the decision. Goes back to the choice between a Formula One race car versus a tank. Speed has nothing to do with it. In no case that I can imagine would speed be the reason to choose between a static method and an instance-level one. People who recommend destruction of a design for specious reasons should be excoriated and removed from positions of influence over that design, if not employment altogether. - Lew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.