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.

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

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.

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

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

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 (So I gues it's the same with Java, altough the JVM might optimize stuff like this. dunno)

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

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).

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

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.

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...

Fields take only the required amount of storage - so a short is smaller then an int. Java will always align fields to a multiple of their size - so that you don't get unaligned access. Access to these fields is not slower then other fields.

On the other hand if you put small data types on the stack or as method parameters then it needs additional instructions to enforce the desired overflow behavior.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org