27

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.

  • 3
    If you're doing any kind of reflection it could slow that down. – Pace Apr 29 '13 at 14:24
  • An intersting question would be: do the unnessisary methods lead to unnessisary imports – Richard Tingle Apr 29 '13 at 14:26
  • 1
    Short answer, yes. But performance is a whole different animal that needs to be attacked in a different way. – Siddharth Apr 29 '13 at 14:26
  • 5
    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. ;) – Joop Eggen Apr 29 '13 at 14:32
  • 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? – durron597 Apr 29 '13 at 14:38
  • Thanks everyone - what about the PermGen space or code cache? Does compiled binary get housed in those areas, regardless of use? –  Apr 29 '13 at 14:52
  • 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! –  Apr 29 '13 at 14:55
  • There are nice pieces of code, like http://stackoverflow.com/questions/4122170/java-change-aeou-to-aeouu that I like to write commented in a text document. I called it an album. I did hear "almanac" or ofcourse "recipes" too. – Joop Eggen Apr 29 '13 at 16:01
  • @Pace, if you are using a non trivial amount of reflection, I would not trust the Unnecessary Code Detector. – emory Apr 29 '13 at 18:43
  • @emory 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. – Pace Apr 29 '13 at 20:36

4 Answers4

31

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.

Joe Ratzer
  • 18,176
  • 3
  • 37
  • 51
  • 1
    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`? – nhahtdh Apr 29 '13 at 14:35
  • 1
    If the JIT compiler removes it I don't see it being an issue. – Joe Ratzer Apr 29 '13 at 14:40
  • 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. – Joe Ratzer Apr 29 '13 at 14:40
  • 6
    +1 on: "I don't think "dead code" will hinder application performance, but it will hinder development performance, which is invariably more expensive." – Max Charas Apr 29 '13 at 15:16
  • 1
    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. – Viliam Búr Apr 29 '13 at 15:31
  • 1
    @ViliamBúr private methods could still be reached by reflection – emory Apr 29 '13 at 16:42
22

It could affect a few things...

  • Size of the application
  • Memory used when application is running
  • Decreased performance on package scanning (if applicable)
Ben
  • 60,438
  • 111
  • 314
  • 488
  • 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! –  Apr 29 '13 at 14:50
  • 2
    @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. – Ben Apr 29 '13 at 15:35
  • Thanks again @Webnet (+1 again) - can you point me to anything specific in the JVM documentation (or anywhere else) to followup on this? –  Apr 29 '13 at 17:40
  • @TicketMonster - http://www.securingjava.com/chapter-two/chapter-two-7.html is a good read, and for a more brief version, see http://stackoverflow.com/questions/12284482/is-the-java-class-file-stored-in-jvm-memory – Ben Apr 29 '13 at 18:22
5

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.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 1
    *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. :( – TheLostMind Jan 15 '15 at 09:48
1

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.

rai.skumar
  • 10,309
  • 6
  • 39
  • 55
  • 3
    If the code is never run, it won't use any heap memory, only PermGen (to store the compiled code) –  Apr 29 '13 at 14:34
  • agree..i just jumped the gun. thanks for correction. have updated my answer. – rai.skumar Apr 29 '13 at 14:37
  • Thanks @rai.skumar (+1) - so all compiled code gets stored in the PermGen? What about the code cache? –  Apr 29 '13 at 14:51
  • If "performance" considered to be execution speed (what I assume here) then how can a bit static mem influence performance (edge cases set aside)? – Mike Lischke Apr 29 '13 at 15:06