12

I am a senior developer, so this appears to me a stupid question. My answer should be NO, or WHAT? NO!!!

But I was in a meeting yesterday, and I was explaining some PMD results. When we get to the "too long method name" issue, I started to explain and the customer said: well, and remember a long method name has an impact on performance, the program run slower.

I said: no, you are wrong, is only a clean code rule, and is important to get a good code, but has nothing to do with performance, the bytecode is similar with different names.

But the client, and there were some people in the meeting arguing in this, was sure about this. They had some projects in that long method names were the cause of poor performance.

The only idea I have is that some introspection or reflection thing has is related to this, but apart from this, I am sure, or I thought I was Sure, the method name length has not any performance impact.

Any idea or suggestion about this?

scunliffe
  • 62,582
  • 25
  • 126
  • 161
ERNESTO ARROYO RON
  • 992
  • 1
  • 9
  • 22
  • 7
    2 weeks ago I wore red socks, and it started raining. I've been sporting blue socks ever since and we've had no rain. That might not sound relevant but is probably the same chain of reasoning your client uses. – ivarni Nov 12 '11 at 18:47
  • @ivarni: you're right, that is exactly what most likely happened. – Michael Borgwardt Nov 12 '11 at 18:50
  • Whoever claims this has no idea how programming languages are implemented, or is so utterly stupid (there's no nice way to say it) that they fail to spot the simplest potential optimizations in implementing them (or, which is probably worse, assume the JVM authors were morons). They also seem to be unable to verify their assumptions properly. –  Nov 12 '11 at 18:50
  • @delnan: that was my first thought, too, but then I stepped back and thought that Java *might* just sport some sort of unique design feature that the OP's situation might just turn out to be plausible :-) – Kerrek SB Nov 12 '11 at 18:52
  • @KerrekSB: Such things would be extremely obscure corner cases, and if they had performance impact, someone would have made up an optimization to nullify that impact when it's not needed. To the best of my knowledge, it's entirely possible to assign indices to all methods, members and variables at compile time, and I believe java bytecode actually does that. Of course you *can* do things with reflection information that are O(n) where n is the length of a method name, but I think it's pretty safe to assume this is not the case (especially considering the general nature of the claim). –  Nov 12 '11 at 18:57
  • thank you. The point is that they were so sure that although I knew they were wrong I started to doubt. What if,... but yes I know is a so silly question,... thank you again – ERNESTO ARROYO RON Nov 12 '11 at 18:57

6 Answers6

21

Arguably it will take more space in memory and storage - so a jar file containing classes with enormous method names will be larger than one with short class names, for example.

However, any difference in performance is incredibly unlikely to be noticeable. I think it's almost certain that the projects where they were blaming long method names for poor performance were actually misdiagnosed. It's not like it would be the first time that's happened.

Of course, the best way to take the heat out of this situation is to provide evidence - if performance is important, you should have tests for performance. Run those tests with long method names, then refactor them to short method names and rerun the tests. I'd be incredibly surprised if there were a significant difference.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    I completely agree. Long method names have no impact on performance. –  Nov 12 '11 at 18:46
  • +1: Very long names (and very short ones) could indicate a peculiar approach to developing which may not have been so concerned about performance and best development pratices. e.g. the longest class names in the JDK appear to have been generated, and perhaps not optimised by hand. – Peter Lawrey Nov 12 '11 at 22:01
  • 1
    I am bit confused because of your answer, my understanding was that in the end once Java code is compiled then it would be bytecode and bytecode certainly doesn't keep the same name of varaibles as developer, they will be translated into instrcutions etc. – pjj Feb 26 '17 at 14:33
  • 2
    @pjj: Yes, but the method names will still be part of the class file, and so they will increase the size of the file on disk and the amount of memory required when loading those classes. Bytecode *does* maintain the names of fields, just not local variables. You can tell this by accessing the fields with reflection - but this question was about *method* names anyway, and again, they're maintained in bytecode. – Jon Skeet Feb 26 '17 at 15:13
  • @JonSkeet Perfect, it clarifies. May be you can add this in your answer, for novice folks like me it is not that obvious. – pjj Feb 26 '17 at 21:29
4

Method names are not just relevant with reflection but also during class loading and of course in both cases a long method names means that at some level there is more for the CPU to do. However, with method name length that are even remotely practical (i.e. not thousands of characters long), I am absolutely certain that it's impossible for this to be significant compared to other things that have to be done during reflection or class loading.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
1

But the client, and there were some people in the meeting arguing in this, was sure about this. They had some projects in that long method names were the cause of poor performance.

It sounds like a total guess being treated as fact. This is just a case of some people's general nuttiness about performance. Even if they happen to be right, it's a total guess.

Every program has room for performance improvement by changing certain things. Guessing does not inform you what those things are.

If two programs that do the same thing have different performance, it only means they've been optimized to different degrees. Your challenge is to explain this.

Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
1

Startup times will be affected positively if class names and member names are shortened. To that end one can use a bytecode shrinker.

For example, yguard (LGPL) can shrink code. It also allows you to deobfuscate stack traces for debugging purposes.

Manually assigning short class and member names for performance reasons is of course a horrible idea.

Ingo Kegel
  • 46,523
  • 10
  • 71
  • 102
0

I think the length of function name impact to performance as followed:

  1. compile time from bytecode to binary code (with java, .net, ..). The byte code still contains file name, class name, package name.
  2. if we use *.lib, *.dll, *.so it may impact to performance (in android for example when you use native code)
  3. when we use native code to call to java function (in java, android)

when a black box (lib file,app) connect to other black boxes (lib file,app) it use function name in header file as the indetification. So I think length of name will impact to performance.

HungNM2
  • 3,101
  • 1
  • 30
  • 21
0

I can't why it can possibly impact performance significantly unless you are pulling method names out yourself through reflection and then render them on an UI. That is obviously not the case. So I'm just confused. Are you sure your client isn't confusing method name with file name or is he thinking about the cases where some really old programming languages do not support super long method names? Depending on how old that person is, their judgement is definitely absurd to a computer scientist. If they can prove their point with fact, they may as well submit it to ACM, Oracle/Sun or MIT to verify their findings.

ttback
  • 2,051
  • 5
  • 27
  • 40