• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Code size

 
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I was wondering if performance is better when you have several smaller files as oppose to one large file.

Basically my chess engine Engine.java, is currently a huge a file, with many methods and instance variables.

My mate said it was better to split it so that the entire program isn't stored in RAM, when only parts of it are needed at certain times.

Is this true? It would however help in coding to have it packaged nicely instead of having to scroll up and down the same class to find something.

Also, since I am calling many methods per second, would it make any performance difference to say call a method from the same class, eg ABC(), than to call it from an object, eg. someObject.ABC() ?

Thanks for any advice.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd vote to split your monster up for design goodness, not performance. The usual advice is write for humans first and optimize only when you can prove you have found the worst performance problem in your system. Trying to second guess the swapping algorithm of the OS or how many instructions are involved in a method call is not the best use of your time.

"Design goodness" is a debatable topic of at least book length. If principles like make a class with only one reason to change, tell don't ask and so on sound interesting, scroll on down to the OO, UML, etc. forum and describe your giant class in a bit more detail.
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just tried splitting a chunk of it off, but I kept get a stack overflow exception, I couldn't figure out why, so I put it back.

So long as performance isn't haltered by having a load of methods/variables in one class, I'm not too concerned.

One more thing, how does final work?
I set an array (instance field) to final, but I was still able to modify the elements of it elsewhere in the code, doesn't look very final to me.

??
[ February 13, 2007: Message edited by: colin shuker ]
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"final" affects only the variable it's applied to. A final variable of array type can't be changed to point to another array. But the array pointed to is just an ordinary array, and its elements can be set. There's no way to make a non-writeable array in Java.
 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!