I have always wondered – when you are thinking about creating an immutable number (a constant), is it smart to use the smallest possible value? For example, if it will only be lower than 255, should I make it a byte? Etc.
It doesn’t make a great difference really, unless you have a very large array.
Also, casting is slow (if it’s necessary to cast that is).
It can be better in large projects, however depending on the datatypes used throughout the code, use of the constant will require parsing (Extra processing) to be used.
Btw, a byte has a max value of 127.
127 on signed, doubled on unsigned
I rarely use byte. Commonly int, long and double because most java API take them as parameters so I’m more concerning about casting cost.
There are no unsigned bytes in Java :clue:
I meant, he may remember that byte is 255 max but java has no unsigned thing like C so it has 127 max.
I try not to restrict myself unless I have a specific reason to use a smaller type.
When in doubt use int and change it later if you need to.
Also premature optimization is the root of all evil. Often the majority of the slowdown in your code is in a tiny percentage of the codebase and more often than not it is in an area you aren’t expecting. Only a profiler will tell you for sure. Readability and simplicity are my most important criteria when writing new code.
Thank you all very much (especially you!), I’ve learned something now 
I can make variables a byte with a value of more than 127 :persecutioncomplex:
using this code
public static int unsignedByteToInt(byte b) {
return (int) b & 0xFF;
}
you can use unsigned bytes, but unfortunatly we use casting -.-
I can’t speak with certainty about byte, but short is probably not worth bothering with except in an array. An array should be packed, so if you need to optimize for space, use the smallest type you can get away with. Outside an array however, a short will take up the size of an int anyway, so there’s not much rationale for using them except as a documentation hint, and even they’ll force users of them to use annoying gratuitous casts, so I’d still avoid using short in any public API.
I think that’s not a thing you should think about even large int Arrays are not that tall… Such stuff is only important if you’r on a system with less memory… but modern PC’s have like 4 GB… In an magazin I found an new Laptop with 12 GB RAM… 
Even if, simply having a look on the size of your data is not enough…
For me Performance is a bit more important… like using ++i instead of i++… not sure about Jaba but in C++ using ++i ist a lot faster :o (So I gues it’s the same with Java, altough the JVM might optimize stuff like this. dunno)
They’re easily faked.
Oh no! What’s wrong with Jaba the Hutt??
He is evil >:(
No need to take 4GB as example. Through 200MB RAM I can still do tons of double operations including multiplying.
you don’t have to cast up
I’d imagine any decent compiler should generate the same machine code for both i++ and ++i, provided the result isn’t used in an expression. In any case, this is surely the mother of all premature optimizations.
Using smaller types, such as short or byte, can hurt performance, depending on the hardware. The registers in modern CPUs are often more then 16-bits long, and so converting the value to a larger one, in order to fit it into a register, and then back, can have a cost on some architectures. On a lot of CPUs, it is also more more expensive to lookup values which are not located exactly on word boundaries. If a word is 32-bits, then an int fits this perfectly. As a result using a short, byte or even a boolean, can end up using the same amount of memory as an int, because the compiler/runtime has padded the value out with extra space.
Unless you need a byte or a short, then just don’t use them. For certain operations, I even prefer to use packed ints instead of byte arrays (i.e. ARGB).
MOAPO! An upgrade of Fuel Air Optimization, which requires a rank of 5 star Java Optimizer! Long cooldown, but immensely powerful! Delivered by a B2 Stealth Optimizer, which is designed to avoid all Common Sense Defence in its operational area!
Sorry, I just had to…
