This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Performance: Constants vs Hard-Coded Text

 
Gabriel Cane
Ranch Hand
Posts: 39
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know that, from a maintenance and code readability point of view, storing text and/or numbers in constants is a good idea. What I would like to know is, from a performance/memory standpoint, which is better?
Will hard-coding text and/or numbers save processing/memory vs. constants, or vice-versa?
Also, is placing all constants in an interface that all classes implement a good idea, again from a performance standpoint?
 
Peter Chase
Ranch Hand
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I vaguely remember from somewhere that constants (static final) defined in a class end up in memory twice (once in the loaded class and once on heap, presumably), while constants in an interface only end up in memory once.
Can anyone confirm whether this is true or false?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gabriel Cane:
I know that, from a maintenance and code readability point of view, storing text and/or numbers in constants is a good idea. What I would like to know is, from a performance/memory standpoint, which is better?
Will hard-coding text and/or numbers save processing/memory vs. constants, or vice-versa?
Also, is placing all constants in an interface that all classes implement a good idea, again from a performance standpoint?

Constants whichs value can be computed at compile time (that is, they are not computed using an expression containing a method call, for example), are inlined by the compiler. Therefore the use of constants (final static fields) doesn't have any performance drawbacks.
Notice that you therefore need to recompile all classes using the constants if change their value!
 
Mark Herschberg
Sheriff
Posts: 6037
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja is correct. Keep in mind if you define

All expressions which can be computed from constants are, in this case, area will be defined at compile time, too, and anywhere it is in the code, it will be replaced with the constant value.
As for putting constants into an interface, that is generally a bad idea. It tends to lead to global constants which goes against the principles of OO. I'm not saying never to do it, but rather just to be careful.

--Mark
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Mark - what's this 'x' operator you're using?
Actually in the given example, area is not defined at compile time, because the length and width were not declared final. Rules for compile-time constants are given in the JLS here - the last two bulleted items allow variables to be part of constant expressions, but only if they are final variables which were themselves initialized with constant expressions. So it can be useful to declare a variable final in a case like this.
 
Mark Herschberg
Sheriff
Posts: 6037
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right! I was being incredibly sloppy. I was going to make them private static final but was being lazy. And then using x. Boy, this is what happens when you don't code for a month!
Shamefully,
Mark
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic