Static methods slower?

Discussion in 'Java' started by =?iso-8859-1?B?QW5kcuk=?=, Jan 10, 2007.

  1. 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é
     
    =?iso-8859-1?B?QW5kcuk=?=, Jan 10, 2007
    #1
    1. Advertising

  2. > 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é
     
    =?iso-8859-1?B?QW5kcuk=?=, Jan 10, 2007
    #2
    1. Advertising

  3. "André" <> writes:

    > 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.
     
    Tor Iver Wilhelmsen, Jan 10, 2007
    #3
  4. André wrote:
    >> 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?


    Whenever anyone asks "is A faster than B" my immediate thought is - why
    not write a test program and measure it?

    Just a thought.
     
    RedGrittyBrick, Jan 10, 2007
    #4
  5. =?iso-8859-1?B?QW5kcuk=?=

    Daniel Pitts Guest

    André wrote:
    > > 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é


    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
     
    Daniel Pitts, Jan 10, 2007
    #5
  6. =?iso-8859-1?B?QW5kcuk=?=

    Mark Rafn Guest

    <> 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 <http://www.dagon.net/>
     
    Mark Rafn, Jan 10, 2007
    #6
  7. =?iso-8859-1?B?QW5kcuk=?=

    Daniel Pitts Guest

    Mark Rafn wrote:
    > 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?"
     
    Daniel Pitts, Jan 11, 2007
    #7
  8. =?iso-8859-1?B?QW5kcuk=?=

    Graham Guest

    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


    André wrote:
    > > 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é
     
    Graham, Jan 11, 2007
    #8
  9. =?iso-8859-1?B?QW5kcuk=?=

    Karl Uppiano Guest

    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.
     
    Karl Uppiano, Jan 11, 2007
    #9
  10. =?iso-8859-1?B?QW5kcuk=?=

    Lew Guest

    Karl Uppiano wrote:
    > 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
     
    Lew, Jan 11, 2007
    #10
  11. =?iso-8859-1?B?QW5kcuk=?=

    Hal Rosser Guest

    "André" <> wrote in message
    news:...
    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.
     
    Hal Rosser, Jan 12, 2007
    #11
  12. =?iso-8859-1?B?QW5kcuk=?=

    Stefan Ram Guest

    "Hal Rosser" <> writes:
    >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.
     
    Stefan Ram, Jan 12, 2007
    #12
  13. Stefan Ram wrote:
    > "Hal Rosser" <> writes:
    > >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.


    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
     
    Faton Berisha, Jan 12, 2007
    #13
  14. On 12.01.2007 12:26, Faton Berisha wrote:
    > 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
     
    Robert Klemme, Jan 12, 2007
    #14
  15. =?iso-8859-1?B?QW5kcuk=?=

    Lew Guest

    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
     
    Lew, Jan 13, 2007
    #15
  16. Daniel Pitts wrote:

    > 5. Go to step 1
    > 12. Go to step 6


    Warning: Goto considered harmful.
    Refactor!
     
    John Ersatznom, Jan 15, 2007
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neo
    Replies:
    1
    Views:
    531
    Scott Allen
    Jan 7, 2005
  2. Andre Charbonneau

    XPath queries getting slower and slower...

    Andre Charbonneau, Feb 15, 2005, in forum: Java
    Replies:
    0
    Views:
    557
    Andre Charbonneau
    Feb 15, 2005
  3. Oliver Wong
    Replies:
    14
    Views:
    1,651
    Chris Uppal
    Jun 13, 2006
  4. lightning
    Replies:
    4
    Views:
    922
    Daniel Pitts
    Oct 30, 2008
  5. Kenneth McDonald
    Replies:
    5
    Views:
    345
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page