Will the size of a java class impact the performance of the application

Question

I am doing a swing based application where I use JTable. I used DefaultCellEditor for one of the column which requires combo box selection. But DefaultCellEditor has many methods which I don't require. So I wrote a custom CellEditor by extending AbstractCellEditor where I have implemented only the required methods. My question is

(in general) if we have a class and if we don't require all the methods of that class is it fine to use it or is it good to write a custom class where we implement only those methods which we require? and

by using custom class will the performance (memory wise) of the application will be improved or it remains same as the class which has all the methods?

Any help will be appreciated.

Bluestone

"premature optimization is the root of all evil" – Code

@Code "premature optimization is the root of all evil" loved it .. :) – Bluestone

Mathias, are you saying that the JVM doesn't load all the methods of a class - only the ones actually called? Do you have a reference for that? – Hinojosa

@MathiasSchwarz classes are indeed loaded lazily, but not their methods/variables e.t.c – Kagoshima

@Code Thanks. c2.com/cgi/wiki?PrematureOptimization Its a good article. – Bluestone

@Code Perfectly apt in this case but you should be aware that that is a partial quotation. The rest of it goes "Yet we should not pass up our opportunities in that critical 3%." – Damascus

Answer 1

Unless you have seriously good grounds for believing that nothing else in the application including the JDK itself uses DefaultCellEditor, you are almost certainly wasting your time by making things actively worse.

You also need to consider that you might have saved maybe 100k of code in extreme cases, where typical JVMS use around a gigabyte to execute. So you may have saved 0.01% of code space. This is not a productive use of your time. The correct procedure is to test and measure where the time and space bottlenecks really are, after the fact. Programmers are notoriously poor at predicting these things.

Damascus

+1. Use the DefaultCellEditor because you know it's going to work and you won't have introduced any bugs. Once you're done, profile the system and if the DefaultCellEditor appears as a hotspot, then consider customizing or rewriting it. Optimize last, when you fully understand the problem space and you've got a working solution. – Hinojosa

Answer 2

The code (the actual bytecode) for this class is only loaded once, in the PermGen region of memory, regardless of how many objects of this type you instantiate.

I would not accept this code since you are duplicating functionality which is already available, and you're not adding functionality to AbstractCellEditor, you're reimplementing code in DefaultCellEditor which has already been (hopefully) tested by Oracle (or Sun).

As EJP said, it's not worth the time and potential to introduce bugs.

Hinojosa

Answer 3

If you create a custom class which contains fewer member objects, then the memory footprint will be lower. The number of methods wouldn't impact the size of the objects, just the size of the class.

In general, I would not prematurely optimise unless you determine that you actually have a problem (i.e. if you have thousands of instances of the object and heap/garbage collector log analysis reveals that you're thrashing the memory and/or have frequent of collections of the old space), because additional code means:

• Additional maintenance (you'd need to ensure that your custom CellEditor is not buggy)
• Additional effort in writing the custom code
• Additional effort in testing the custom code

AFAIK, a CellEditor is instantiated as and when needed, so you wouldn't save much memory anyway.

Flowerage

Your first sentence is only true if nobody else uses the replaced class, in this case DefaultCellEditor, and it doesn't answer the question, which is about methods, not 'member objects'. – Damascus

True, but that sort of thing is difficult to measure because of hard references to objects from other objects. If he passes something in to a constructor that's already referenced somewhere else in the object graph, the shallow footprint might increase but the total memory used doesn't. – Hinojosa