• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

array declaration and initialization

 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Considering an assignment where three arrays are each used only one time, I had originally placed them within the method that used them, and declared and initialized them just before I used them - according to my understanding of The JavaRanch Style Guide Section 5.3.
I was nitpicked to move them outside the method and make them final. I'm assuming a performance gain is realized with this change. Considering that each array is used only once and by only one method, I'd prefer that they were not class members and just belonged to the method that used them. So, is this nitpick to realize the performance gain or is it just gearing up for the following assignment that will reuse each array?
 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, that is a tricky one.
The first two sentences of Section 5.3 are:
Try to always initialize all variables when they are declared.
and
Try to not declare a variable until just before it is used unless it will impact the performance of the code.
Which one do you think Marilyn emphasized in your example?
 
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Constants are figured out at compile time, not at runtime. Thus optimized.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marilyn deQueiroz:
Constants are figured out at compile time, not at runtime. Thus optimized.


Righto. Is this the best practice for any data item that doesn't need to change? - even for a lowly int that is used just once in a method somewhere?
[ April 26, 2002: Message edited by: Dirk Schreckmann ]
 
Ranch Hand
Posts: 301
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dirk Schreckmann:

Righto. Is this the best practive for any data item that doesn't need to change? - even for a lowly int that is used just once in a method somewhere?


It really isn't a constant, though, when you do this because of scope (you may want to use the same variable name in another method). Plus, it's a primitive and not an object so I'm not sure if the performance hit is really the same.
With the Array, since you fix the size and initialize the values and nothing will change them they really are constants.
Of course, I coul dbe way off base...
 
Marilyn de Queiroz
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dirk Schreckmann:
Is this the best practice for any data item that doesn't need to change? - even for a lowly int that is used just once in a method somewhere?


If you are only using an int once, I would question whether it really needs an identifier.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Constants are figured out at compile time, not at runtime. Thus optimized.
But an array is not a constant, as far as the compiler is concerned. Check out JLS 15.28. The only reference types which can be considered constants are Strings. It might have made sense to include other immutable types in this rule - but arrays are never immutable anyway. Declaring an array reference as final may prevent anyone from reassigning the reference to a different array, but it can't prevent someone from changing the contents of the array. Even if you know you never do anything to change the array, the compiler will not perform any optimizations on the array based on the idea that it's a constant.
The only way I can see any performance benefit to declaring the array outside the method is if the method will execute more than once. If that's not the case, I don't see any benefit. And limiting the scope of variables as much as reasonable is always a good thing, in my opinion. OK, I'm cheating because if you can think of a case where it's not a good thing, then limiting scope in that case is not reasonable. It's a truism - so sue me.
 
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And yes, moving them outside to the class level gets you ready for 4B. I'm sure it could be done, but I have yet to see an attempt where these arrays could be worked into just a method, and the code still be clean and readable.
Forgetting all the optimization part, since Jim pointed out that there really isn't any benefit, let's look at design. To me, it makes sense that these arrays are at a class level. What is the whole point of the class? It's to print out numbers from 0 to 99 in word format. So doesn't it make sense that the class itself should know the words that it is going to print? Shouldn't those words be accessible at any time in the program, and not be buried in a method, where it's scope is greatly reduced (unless you plan on passing the arrays around, or constantly having to refer to the containing methods)?
 
Michael Pearson
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:

The only way I can see any performance benefit to declaring the array outside the method is if the method will execute more than once.


This depends on the number. As the number gets larger there is no way the methods will not be executed mutliple times. So, moving them to class level has benefits for this assignment.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Pearson:
As the number gets larger there is no way the methods will not be executed mutliple times. So, moving them to class level has benefits for this assignment.


Considering the first assignment in this series of two related assignments (ok, fine, it's Java 4a Say):
Of course, for the purposes of this assignment, we do know that each array will not be accessed more than once and in fact one or all of the arrays might never be used! So, were they only declared and initialized when they were used the one time, then any goals of optimization would be realized. For the next assignment, the number of potential array accesses are quite different...
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If a goal of this assignment were more on optimization, would it not be highly more efficient to use three switch constructs rather than the three arrays?
It would seem to me that with the arrays, many objects are instantiated but never used. While with the switch constructs, only the objects that are actually used would be instantiated.
Of course, one of the purposes of the assignment is to learn about using arrays. So, I understand why we are using arrays.
However, the other purpose of this assignment is to learn about string concatenation. But, I'd bet that in the final product, not a single string concatenation exists - we're outputting everything as we decide to use it. Or was that whole purposes clause regarding learning about string concatenation really just a ploy to get us to use them and then be nitpicked to not use them so we could learn that it's not very efficient?
All I'm doing here is suggesting that maybe considering a revision of the purposes statement is in order.
Thanks
 
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Marilyn asked me to jump in here.
I think this is certainly a debatable point. Probably the best way to get to the bottom of it is to look at the byte code. Of course, you might get different byte code depending on which compiler you use.
Some of the points worth debating include:
  • limiting the scope by putting it in the method, thus making sure that other bits of code don't monkey around with your array!
  • Putting a bigger array outside of the method to make it more readable - a big array in a method is, IMO, ugly clutter.
    If the array is really small, and you are sure you are using the method just once, I would probably put it in the method.
    When I encounter a debatable point like this, I tend to think about what might I do in the future. I'm usually against using the crystal ball in my development, but somethings gotta help get me off the fence! In this case, I would probably put the array outside of the method.
    Good question!
  •  
    Michael Pearson
    Ranch Hand
    Posts: 351
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Dirk Schreckmann:
    But, I'd bet that in the final product, not a single string concatenation exists - we're outputting everything as we decide to use it. Or was that whole purposes clause regarding learning about string concatenation really just a ploy to get us to use them and then be nitpicked to not use them so we could learn that it's not very efficient?


    We warned you about the Cattle Drive didn't we?
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic