3

I had an impression that in for loop condition, using a variable in place of the method call to string function length() is always better. Though it seems that it is just opposite as analysed by Saint Hill in the following answer

https://stackoverflow.com/a/11876086/6517886

for (int i = 0; i < data.length(); i++) {
    ...
}

is faster than

final int len = data.length();
for (int i = 0; i < len; i++) {
    ...
}

What is the reason?

Yogesh Kaushik
  • 440
  • 3
  • 14
  • because in the latter one, you are first getting data length in a variable and then using this variable in for loop. – kritikaTalwar Mar 30 '18 at 09:46
  • 1
    @kritikaTalwar in that case I would expect the second version to be faster, which is the opposite of what the question is asking. – Federico klez Culloca Mar 30 '18 at 09:47
  • @Federico exactly – Yogesh Kaushik Mar 30 '18 at 09:49
  • Do you mean better as in faster? If so, you should measure it (https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) , I doubt that it actually will be faster. The quoted answer is discussing charAt() performance and not for loop performance, isnt it? – lwi Mar 30 '18 at 10:04
  • 3
    Bear in mind that answer was written in **2013**, and the answerer points out himself that as of 2016, many of the results have been invalidated (although not testing the same thing, it's indicative of the optimisation increase in the JVM). – hnefatl Mar 30 '18 at 10:05
  • @Iwi, yes, better as in faster. I doubt it as well that is why I asked the question as had no other way to verify it. If you go through the quoted answer, it has mentioned this explicitly that the first one is faster, and in comment section someone gave an explanation to why, but I didn't get that. – Yogesh Kaushik Mar 30 '18 at 10:11
  • According to @Saint Hill : Defining a variable, at all, requires a stack operation in the method byte code. But the optimizations, from recognizing your algorithm, could fast track that repeat operation in the actual machine code, without the overhead of variable alocation. Such optimizations sometimes exist in the bytecode compilers, sometimes not. It all depends on whether the jvm is smart enough :-) ..............................This makes sense, but didn't get the full picture – Yogesh Kaushik Mar 30 '18 at 10:16
  • In later case in loop it will call String length()(Actually get Char Array length ) method each iteration, that method call is time consuming, instead of this if you keep string length in variable then it would be local access to loop in same memory stack hence no time overhead. So in my view its better to keep this in variable. – Afgan Mar 30 '18 at 10:59
  • Creating new object is an expensive operation that is why the first one is faster. – Prabhav Mar 30 '18 at 11:20
  • @Prabhav Where did you see new object creation? – DontPanic Mar 30 '18 at 11:40
  • I am talking about creating new variable "len" – Prabhav Mar 30 '18 at 11:41
  • 2
    @Prabhav it's not an object creation. It's just an int variable in constant pool. It isn't expensive operation. – DontPanic Mar 30 '18 at 11:45
  • Ohh, thanks I was considering it as expensive as new Object. – Prabhav Mar 30 '18 at 11:47
  • @Prabhav you're welcome) – DontPanic Mar 30 '18 at 11:48
  • Assume that you are doing some calculations of stock. You are in the office and store house is 10 feet away, your task is to tell the stock of oil in the store house. What would you prefer, going to store every time and getting the total stock or going once to the store house gets the stock and noting it somewhere? – Arun Sudhakaran Apr 02 '18 at 08:19

1 Answers1

1

Defining a variable, at all, requires a stack operation in the method byte code.

No it doesn't. It requires allocation of an extra slot in the stack frame when the method is called. The stack frame is allocated anyway. There is no overhead in allocating an extra slot. The only thing that changes is a constant in the byte code stating how big the stack frame needs to be.

Specifically, there is no bytecode instruction for declaring a local variable.

But the optimizations, from recognizing your algorithm, could fast track that repeat operation in the actual machine code, without the overhead of variable allocation.

There is no such overhead.

This is all BS.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    The question is not about, what he said is right or not. He proved it in a benchmark testing that the first gives better result than the other one. Why? is the question. The only logical reason, I can think here is that the tests were performed long back, and JVMs are a lot better now. But even then what was the reason behind it? – Yogesh Kaushik Mar 30 '18 at 15:25
  • Come off it. Your *entire question* is about this quotation. I refuted it. If you didn't want that, why quote it? If you disagree with my *answer,* you would have to produce (a) the byte code instruction and (b) the corresponding machine code instruction that is/are executed on declaration of a local variable, and you can't, because there aren't any such instructions. The reason is clearly that `String.length()`, being a very frequently executed operation, has a greased path in the HotSpot JVM. That's what HotSpot is for. – user207421 Mar 30 '18 at 22:28
  • No, my question is not about his quotation. My question is how come that is fast. If I would have agreed with his answer, why would have I asked the question. I just quoted his answer so that one can know his views about it, which might be right or wrong, I guess i will remove that as it it confusing. "String.length(), being a very frequently executed operation, has a greased path in the HotSpot JVM. That's what HotSpot is for" might be the answer one is looking for, Thanks. – Yogesh Kaushik Apr 02 '18 at 07:51