Static methods slower?

  • Thread starter =?iso-8859-1?B?QW5kcuk=?=
  • Start date
?

=?iso-8859-1?B?QW5kcuk=?=

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=?=

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é
 
T

Tor Iver Wilhelmsen

André said:
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.
 
R

RedGrittyBrick

André said:
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.
 
D

Daniel Pitts

André said:
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
 
M

Mark Rafn

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.
 
D

Daniel Pitts

Mark said:
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?"
 
G

Graham

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
 
K

Karl Uppiano

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.
 
L

Lew

Karl said:
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
 
H

Hal Rosser

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.
 
S

Stefan Ram

Hal Rosser said:
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.
 
F

Faton Berisha

Stefan said:
The difference between

»avoid whenever possible«

and

»use (only) when necessary«

might be considered to be somewhat subtle.


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
 
R

Robert Klemme

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
 
L

Lew

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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top