Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How to decide...short, long, int, byte, etc.  (Read 2231 times)
0 Members and 1 Guest are viewing this topic.
Offline Conner_

Senior Newbie




~ Java Game Dev ~


« Posted 2011-09-19 02:40:00 »

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: connergdavis
My current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.
Offline counterp

Senior Member


Medals: 11



« Reply #1 - Posted 2011-09-19 02:48:03 »

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

Senior Newbie





« Reply #2 - Posted 2011-09-19 02:53:16 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ReBirth
« Reply #3 - Posted 2011-09-19 04:06:40 »

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.

Offline ra4king

JGO Kernel


Medals: 347
Projects: 3
Exp: 5 years


I'm the King!


« Reply #4 - Posted 2011-09-19 04:10:07 »

There are no unsigned bytes in Java Clueless

Offline ReBirth
« Reply #5 - Posted 2011-09-19 04:15:59 »

I meant, he may remember that byte is 255 max but java has no unsigned thing like C so it has 127 max.

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #6 - Posted 2011-09-19 04:42:55 »

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

Senior Newbie




~ Java Game Dev ~


« Reply #7 - Posted 2011-09-19 14:47:59 »

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 Smiley

I can make variables a byte with a value of more than 127  persecutioncomplex

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

Junior Member


Projects: 1



« Reply #8 - Posted 2011-09-19 14:54:00 »

   
using this code


1  
2  
3  
public static int unsignedByteToInt(byte b) {
   return (int) b & 0xFF;
}


you can use unsigned bytes, but unfortunatly we use casting -.-
Offline sproingie

JGO Kernel


Medals: 202



« Reply #9 - Posted 2011-09-19 16:24:00 »

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.
 
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline R.D.

Senior Member


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #10 - Posted 2011-09-20 02:05:04 »

I think that's not a thing you should think about Smiley 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... Cheesy 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 Shocked (So I gues it's the same with Java, altough the JVM might optimize stuff like this. dunno)
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #11 - Posted 2011-09-20 02:07:30 »

There are no unsigned bytes in Java Clueless

They're easily faked.

Offline ra4king

JGO Kernel


Medals: 347
Projects: 3
Exp: 5 years


I'm the King!


« Reply #12 - Posted 2011-09-20 04:01:58 »

......not sure about Jaba but.....
Oh no! What's wrong with Jaba the Hutt??

Offline R.D.

Senior Member


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #13 - Posted 2011-09-20 10:22:19 »

He is evil  Angry
Offline ReBirth
« Reply #14 - Posted 2011-09-20 11:38:27 »

No need to take 4GB as example. Through 200MB RAM I can still do tons of double operations including multiplying.

Offline counterp

Senior Member


Medals: 11



« Reply #15 - Posted 2011-09-20 15:40:27 »

   
using this code


1  
2  
3  
public static int unsignedByteToInt(byte b) {
   return (int) b & 0xFF;
}


you can use unsigned bytes, but unfortunatly we use casting -.-

you don't have to cast up
Offline BoBear2681

JGO Coder


Medals: 18



« Reply #16 - Posted 2011-09-20 17:15:38 »

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 Shocked

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

JGO Coder


Medals: 10



« Reply #17 - Posted 2011-09-20 17:34:40 »

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

Offline theagentd
« Reply #18 - Posted 2011-09-21 00:04:03 »

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 Shocked

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

Myomyomyo.
Offline ra4king

JGO Kernel


Medals: 347
Projects: 3
Exp: 5 years


I'm the King!


« Reply #19 - Posted 2011-09-21 04:14:11 »

@theagentd
LOL!

@Riven
I saw youuuuuuuuuuu Wink

Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #20 - Posted 2011-09-21 06:09:07 »

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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!