aspose file tools*
The moose likes Performance and the fly likes Effect of lines of code in a Class on application performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Effect of lines of code in a Class on application performance" Watch "Effect of lines of code in a Class on application performance" New topic
Author

Effect of lines of code in a Class on application performance

Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 45
Suppose a class (class A) contains 30000 lines of code.
Although its better to write the code in separate classes with loose coupling, modular approach and encapsulation but does it make a difference performance wise.

Is it better to divide the code into separate classes, say class B, class C and class D when we already know that all the classes B,C & D will be instantiated simultaneously at runtime?
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7635
    
  19

Abhishk Singh wrote:Although its better to write the code in separate classes with loose coupling, modular approach and encapsulation but does it make a difference performance wise.

Simple answer: Don't know, but it's likely to be negligible.

Is it better to divide the code into separate classes, say class B, class C and class D when we already know that all the classes B,C & D will be instantiated simultaneously at runtime?

Assuming you're doing so for the reasons you specified above: YES.

Clarity, flexibility and (most important of all) correctness are FAR more important than efficiency, unless you're working on something like a number cruncher for the Hadron collider - in which case you're unlikely to be using Java.

Get it right. Then, if (and only if) you need to, make it fast.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11229
    
  16

Remember...if you micro-optimize so that your code runs 1/100th of a second faster, but writing/debugging/maintaining it becomes harder (therefore taking longer), your code is going to have to run a LOT before you recoup that extra hour you spent debugging because the code was hard to read.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 45
Thanks for the inputs.
I agree with the points both of you make. The current situation at my hand is such that I have a class which has a large number of lines of code. The code is tested and running fine. In fact it is old code and has been running properly for years. I am looking for measures required to perform performance tuning of the code.
Dividing the large class code to small classes will involve a lot of impact analysis and testing. So need your inputs on the line that whether this exercise of breaking the code to small classes is worth the effort.
Also, is it more memory intensive to have a large class instead of having the code divided in small classes, as I have already mentioned as per the requirement all classes will be initialized simultaneously.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11229
    
  16

I am by NO means an expert on this...but I'll give you my thoughts anyway.

Don't assume you know where you need to optimize. Breaking the code into smaller classes might help you, but it might not. You'd be much better off using a profiler to see where things are really slowing down. Maybe your database calls can be optimized. Maybe you are doing some major computations you don't need, or doing them over and over when you could be caching the results.

The real point here is that you don't know where the slowdown is, so doing anything is premature. Find out the reality of where any bottlenecks are, and focus on that.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7635
    
  19

fred rosenberger wrote:The real point here is that you don't know where the slowdown is, so doing anything is premature. Find out the reality of where any bottlenecks are, and focus on that.

@Abhishk: And in addition to Fred's excellent advice, I'd just add this: If it ain't broke, don't fix it.

If you find that having such a monolithic class affects things like flexibility, or causes you do write "work-arounds" - which you're only likely to discover when you actually need to change something - then make sure that any project that requires such a change includes the time needed to redesign the class properly (note my signature below ).

And if you think it might, bring it to the attention of your lead so that they're aware of the situation.

Winston
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2320
    
  28

Refactoring the code while you are optimizing it is a great idea! However, just refactoring code may not lead to improved performance. You need to find bottlenecks, and do some sort of big-O analysis to find ways to optimize the code. If the code is seriously sub optimal, you might end up redesigning it anyways. If it's not too bad, and just fixing it a little bit will improve performance, you should really do what is needed.

I would first try to understand the code and its bottlenecks before coming up with the solution. Once the problem is well understood, the possible solutions will be very evident.
Teo Filimon
Greenhorn

Joined: Aug 18, 2013
Posts: 14

Instantiating classes is an expensive operation. Dividing a big class into sub-classes can be a nice exercise to understand what it does better but it will be slower for sure. And also take into consideration how many times you will need to instantiate B, C and D for every instantiation of A. What i would do in your place (and i have done it ) is test out how long it takes with the big class and then how long it takes with the smaller classes. Compare the durations and if the gain in clarity for the future is worth the performance loss in the present (CPUs tend to get faster as time goes by) go for it. If not, don't
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7635
    
  19

Teo Filimon wrote:Instantiating classes is an expensive operation...

That's a very categorical statement. "Expensive" in relation to what?

My 7-year old clunker Dell desktop machine can happily instantiate upwards of 10 million fairly simple non-cached objects a second, so I'd be very careful about advising that you factor this in when making any decision about efficiency. The fact is, objects take as long to instantiate as they take, and if you need them, you can't avoid the expense; so the only possible thing that might be a factor is the difference in time it takes. And if it's enormous, then plainly your design wasn't very good to begin with.

Winston
Teo Filimon
Greenhorn

Joined: Aug 18, 2013
Posts: 14

Sorry that i sounded so categorical But i was looking to answer the question that started this topic and the truth is:
- if you convert class A to classes B,C,D this will not be faster (if you don't optimize in other ways) because indeed it has a cost
- and the second part of my answer is a way to determine this cost:
- if you insantiate A once and this means B,C,D each get instantiated once it might be worth the cost
- if you instantiate A once but this generates 100 instantiations of B, 100 of C and 100 of D it's already beginning to sound iffy to me and this is where some measurements would help

IMHO classes generally look good in the beginning (OOP wise, clarity wise) and then they evolve towards greater efficiency as you add more and more to them. This is why they lose their nice look. If it all goes into the heap anyway it's perfectly feasible large classes can exist if efficiency is a top priority (as long as someone understands them).
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11229
    
  16

Teo Filimon wrote:the truth is:
- if you convert class A to classes B,C,D this will not be faster (if you don't optimize in other ways) because indeed it has a cost

I don't know - this is not really my area. But what if A is bigger (i.e. contains everything), then won't it take longer to create A than B? Is it not possible that B, C and D may each take <one time unit> each, but because A is so big, it takes <seven time units>? So in this case, B, C and D could be faster.

And if A takes 1000 times longer than B, C and D, I could create 500 Bs, 200 Cs, and 30 Ds in less time...

Any time someone says "This is how it is", I immediately question it...do you have any empirical evidence that what you say is true?
Teo Filimon
Greenhorn

Joined: Aug 18, 2013
Posts: 14

I just wrote some simple code (stupid by any standard but does the job) to better express what i mean:



And some benchmark code:



I have run this on an Android emulator. For one million iterations (and the proportion is constant for any no. of iterations) i get:
- 12251 millis for instantiating 1 million AB objects
- 22105 millis for instantiating 1 million A objects and 1 million B objects
- and this is the favorable case when:
- i'm not even considering the instantiation of an encapsulating class containing A and B
- i am considering an AB to A and AB to B relation of 1-to-1, because it can also be 1-to-many
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2320
    
  28

So, you are worried about an overhead of 9 microseconds per object eh? yes, if you are building an application that needs to do 1 billion loops a second then you will need to start worrying about limiting the number of objects created. In 17 years of working in Java, I've been worried about that much performance in only one employer, and what we were doing is building a search engine there. In most applications, the cost of IO will far outstrip the cost of creating objects. You won't get too much performance gain by shaving off 9 microseconds, when it takes milli seconds for the disk to spin. The pros of having easier to understand code will far outstrip the 9 microsecond gain. In the company where we built search engine, we were worried about things like this, and the most heavily used objects were reused. For example, while reading a record from the File, we will not create a Java bean for every record. Instead there was a big buffer of Java Beans that we will instantiate on start up and on every request, we will fill the buffer with data from the file. Again, unless you are building something like a search engine where having results in microseconds is like an absolutely necessary, I wouldn't worry about the cost of object creation

Teo Filimon
Greenhorn

Joined: Aug 18, 2013
Posts: 14

Normally i do agree with you but i don't think this "performance freak" (which i agree that i am) scenario is that exotic, everyone must judge for themselves. I agree with you that you can reuse objects (if indeed it's possible in the context of the topic starter) but that's only shaving the constructor cost, not the field/method accesses in the extra object. On Android it can make your day if you shave off 10 milliseconds of a response time or if you can save a bit of battery in a service that's running forever because not everyone has a quad-core phone yet. The user will be happy if the app is fast but if it's instantaneous impressed is the better word. It's up to each and every one of us whether we value this overhead or not (the important thing is that we measure it). Sorry, for me clarity and efficiency are on 2 opposite sides of the spectrum and they rarely meet, and the problem is i'm a fan of both of them myself
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Milliseconds or microseconds?

But anyway I don't agree with you that you should measure possible speed improvements. First of all you should only consider doing that if you actually need speed improvements. And second, if you do need speed improvements you should only consider options which could reasonably be expected to yield non-trivial speed improvements. So the original poster's idea of creating four objects instead of one shouldn't be rejected for creating three more objects. And it shouldn't even be questioned unless the need for speed is extreme. Which as far as we can see isn't the case.

The general advice for beginners about efficiency should be "Don't worry about it yet". Beginners are greatly at risk of believing half-baked ideas, of which there are thousands circulating in the area of performance. They are unable to evaluate those ideas and reject the ideas which are exotic or just plain rubbish. Having them consider any of those ideas is in my opinion abusive and will distract them from learning the language properly.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Effect of lines of code in a Class on application performance