byte/short Vs int as for loop counter variable

Question

Is it a good practice to use byte/short as counter variable when we know the exact number of loops? for example

for (byte i = 1; i <= 26; i++)

vs

for (short i = 1; i <= 26; i++)

vs

 for (int i = 1; i <=26; i++)

Peter Lawrey · Accepted Answer · 2021-09-24T10:18:54.520

9

It is more likely to be confusing than helpful. Most developers expect to see an int value and you only have 32-bit or 64-bit registers in your CPU so it won't change how your program works or performs.

There are many options which work and are not harmful to your program but you need to think about the poor developer who has to read it and understand it later, this could be you 6 months from now. ;)

It is also not worth making such a change even if the performance were faster unless it was dramatically faster. Consider this change.

for (byte i = 1; i <= 120; i++)

or

for (byte i = 1; i <= x; i++)

You might thing this is fine as 200 < 2^8 and it compiles just fine, but it's actually an infinite loop.

You have to ask the question; How much faster does it have to be, if you increase the risk of introducing a bug later?

Usually the answer is it has to make my whole program significantly faster in a way I have measured (not just the bit you change) AND I have to need it to be significantly faster.

edited Sep 24 '21 at 10:18

answered Dec 04 '13 at 08:59

Peter Lawrey

525,659
79
751
1,130

@Masud Correct, that's my point, it still compiles just fine ;) – Peter Lawrey Dec 04 '13 at 09:11
@MaheshVarma It is usual to know when changes can improvement performance and when you should avoid using such tricks. In this case, it doesn't help, but other tricks can help in other situations, but you might still avoid them if they are not needed. – Peter Lawrey Dec 04 '13 at 13:07
This doesn't answer the question. The byte type is not sufficient for the number of intended loops. – iheanyi Sep 23 '21 at 15:23
@iheanyi You are right that 200 is too large for a signed byte. – Peter Lawrey Sep 24 '21 at 10:19

score 9 · Answer 2 · answered Dec 04 '13 at 08:59

9

Short answer: No.

Long answer: No, because CPU's are optimized for integer operations. If you work with bytes or shorts, the CPU constantly has to convert it to integers and back, generally by applying bitmasks.

answered Dec 04 '13 at 08:59

Martijn Courteaux

67,591
47
198
287

CPUs have native byte and short operations and they not any slower than int operations. – Peter Lawrey Dec 04 '13 at 09:01
8

@PeterLawrey: Sounds interesting. Do you have any documentation on this? – Martijn Courteaux Dec 04 '13 at 09:04
@MartijnCourteaux, Thanks a lot, Very helpful to my project, may I ask a reference to this (CPU's are optimized for integer operations)? – Gholamali Irani Dec 22 '17 at 22:32

score 3 · Answer 3 · answered Dec 04 '13 at 09:05

3

When you perform some operations on short or byte variable you have to explicitly typecast it back to the required type in java. So it is preferred to use int in place of byte and short. Example :

short s = 0;
s= (short) (s+10);

If you do not typecast it to int it will throw compile time error : Type mismatch: cannot convert from int to short So it is preferred to use int.

answered Dec 04 '13 at 09:05

Nishant Lakhara

2,295
4
23
46

I am sure there will be no operations on them @nishu – MaheshVarma Dec 04 '13 at 09:42
Internally short and byte will be treated as int only. For readiness you can use short or byte, doesn't matter. I am not sure if it will have any performance issues.You are incrementing short and byte everytime in the loop so you are doing operations.It looks like typecasting is done in case of ++ operator internally. i++ can be rewritten as i = (short)(i+1); – Nishant Lakhara Dec 04 '13 at 09:44

score 1 · Answer 4 · answered Dec 04 '13 at 09:00

1

No it is not.

byte and short variables are 32bit/64bit size at this point and the VM is optimized for int.

"Premature optimization is the root of all evil"

answered Dec 04 '13 at 09:00

keiki

3,260
3
30
38

I'm giving a point for this comment because it targets the JVM, not the CPU architecture. Am I odd for not caring about the underlying architecture when I'm programming against a virtual machine which should be shielding me from such things? My initial instinct was to do it anyway, but I trained myself to just think that Java IS the computer. – Gimby Dec 04 '13 at 09:55

score 0 · Answer 5 · answered Dec 04 '13 at 08:59

0

If range of data type not exceed in your scenario. There is no issue in both cases.

But int is preferred.

answered Dec 04 '13 at 08:59

Ruchira Gayan Ranaweera

34,993
17
75
115

score 0 · Answer 6 · answered Dec 30 '19 at 17:02

It also takes a row of memory which usually is 4 or 8 bytes. This means there will be no optumization for memory usage too.

Also If your system uses fragmentation algos for deviding rows of memory to partial addressing of these values, Its adressing algorithm will cost much!

Bathsheba · Answer 7 · 2013-12-04T09:07:36.297

-1

As a starting point, use int which is probably native to the architecture and you'll avoid possible implicit conversions when comparing i with other bits and pieces. So my bet is that both byte and short will wind up being slower.

A far cuter optimisation would be to use ++i rather than i++, as the former will never be slower than the latter. (Conceptually i++ has to return a copy even though it will be optimised out by a good java compiler).

edited Dec 04 '13 at 09:07

answered Dec 04 '13 at 09:01

Bathsheba

231,907
34
361
483

a byte in Java is an 8-bit signed integer. – JB Nizet Dec 04 '13 at 09:02
@JB Nizet: Oops you're correct. I was thinking about char. I'll amend after a coffee. – Bathsheba Dec 04 '13 at 09:03

byte/short Vs int as for loop counter variable

7 Answers7