Does "dead" code hinder Java application performance?

Question

I just installed the Unnecessary Code Detector for Eclipse and ran it on my project. I see a lot of so-called "dead code". Although, from an organizational standpoint, it makes sense to remove dead/unnecessary code, it got me thinking:

Does dead code actually hinder a Java app's performance?!?!

To me, if code is truly "dead", it never gets executed, so I don't see how removing it (again, except for organizational/housekeeping/code cleanup purposes) could ever improve performance.

Polymer

If you're doing any kind of reflection it could slow that down. – Deauville

An intersting question would be: do the unnessisary methods lead to unnessisary imports – Stockholm

Short answer, yes. But performance is a whole different animal that needs to be attacked in a different way. – Consentaneous

I am a code collector too, but dead code should since VCS be removed or copied to ones code album. It hinders the performance of the programmer. So costs money in contrast to application performance. ;) – Patently

Sometimes I intentionally write dead code, because it makes sense. For example, I might put a getter method on a field that I might want later because it's reasonable to be exposed (not every field, just the ones that make sense), but not use it right away. Is this bad style? – Potluck

Thanks everyone - what about the PermGen space or code cache? Does compiled binary get housed in those areas, regardless of use? – Polymer

And thanks for the suggestion @JoopEggen (+1) - could you please elaborate what you mean by code album? Nothing came up when I googled that term and I'm not at all familiar with it. But it sounds interesting! – Polymer

There are nice pieces of code, like https://mcmap.net/q/189800/-java-change-225-233-őű-250-to-aeouu-duplicate that I like to write commented in a text document. I called it an album. I did hear "almanac" or ofcourse "recipes" too. – Patently

@Pace, if you are using a non trivial amount of reflection, I would not trust the Unnecessary Code Detector. – Rotarian

@Rotarian Good point. The same would go if you are using any kind of AOP frameworks or frameworks that make use of reflection under the hood. – Deauville

Answer 1

It could affect a few things...

• Size of the application
• Memory used when application is running
• Decreased performance on package scanning (if applicable)

Nucleoplasm

Thanks @Webnet (+1) - one thing I'm still not understanding is why the dead code would hog up heap memory when the app is running. Can you elaborate a bit? Thanks again! – Polymer

@TicketMonster - I believe a running application needs to keep an "index" of sorts for objects, so when they're imported it knows they're there and where to find them. While the footprint is small, depending on how much "dead code" you've got, it could add up. – Nucleoplasm

Thanks again @Webnet (+1 again) - can you point me to anything specific in the JVM documentation (or anywhere else) to followup on this? – Polymer

@TicketMonster - securingjava.com/chapter-two/chapter-two-7.html is a good read, and for a more brief version, see #12284982 – Nucleoplasm

Answer 2

I don't think "dead code" will hinder application performance, but it will hinder development performance, which is invariably more expensive.

Where possible the JIT compiler may remove this kind of dead-code - see dead-code elimination. I suppose in theory if the JIT compiler removed huge amounts of dead-code it could impact initial compilation.

However I doubt this would occur in practice, and I'd only recommend dead-code removal to make development easier/faster.

Avina

I have no objection against the hinder development performance, but do you have anything to back up don't think "dead code" will hinder application performance? – Retaretable

If the JIT compiler removes it I don't see it being an issue. – Avina

However, I made sure I said "think" because I'd prefer to actually test it myself to make sure it didn't slow down code. – Avina

+1 on: "I don't think "dead code" will hinder application performance, but it will hinder development performance, which is invariably more expensive." – Contusion

Would the compiler remove a public method, which is never used in the program? I doubt that, because in theory the public method could still be reached by reflection. – Zooid

@ViliamBúr private methods could still be reached by reflection – Rotarian

Answer 3

It could affect it a bit, but the JIT compiler should be able to detect and eliminate methods that are never used. And even if it doesn't, the overheads (memory, load time, JIT compilation time, etc) are likely to be small.

A much better reason to eliminate dead methods is to get rid of "old stuff" that makes your codebase harder to read, test, maintain. If this is code that you might conceivably need again, you can always get it back from version control.

---

What if I ask the user which method do you want to call? , take the input as a String and then invoke that method using reflection?. The JIT can't say which method will be used so it can't remove any methods :).

Good point. So it probably won't eliminate methods in practice. (But it could ... if the classloader knew where to reload the method from ...)

Dead methods increases method area in JVM.

Yes, though the percentage memory increase is probably insignificant. And the consequent performance reduction is probably even less significant.

Also a method that is never called will never be JIT compiled, so you are likely to not incure 50% or more of memory usage for a typical live method.

So too much dead code miight lead to unloading of classes from the method area (heap) which could affect app performance. am I right?.

That is highly unlikely. A class will only be unloaded if nothing references it and its classloader is also unreachable. And if it does happen, the class would not be used again anyway, so it is right to unload it.

Tilsit

JIT compiler should be able to detect and eliminate methods - What if I ask the user which method do you want to call? , take the input as a String and then invoke that method using reflection?. The JIT can't say which method will be used so it can't remove any methods :). Dead methods increases method area in JVM. So too much dead code might lead to unloading of classes from the method area (heap) which could affect app performance. am I right?. PS : I apologize for trying to answer and asking a question at the same time. :( – Basrhin

Answer 4

It could affect performance of your application.

Edit

One way to look at it is; dead code is going to add some extra memory to your running application. So it will impact application performance as well.

Homology

If the code is never run, it won't use any heap memory, only PermGen (to store the compiled code) – Fewell

agree..i just jumped the gun. thanks for correction. have updated my answer. – Homology

Thanks @Homology (+1) - so all compiled code gets stored in the PermGen? What about the code cache? – Polymer

If "performance" considered to be execution speed (what I assume here) then how can a bit static mem influence performance (edge cases set aside)? – Angle