13

In my Java class we have just learned about of each of the following primitive data types:

  • byte
  • short
  • int
  • long

Since the long data type contains the most bits, wouldn't it make sense to exclusively use the long data type to avoid restrictions?

Questions

  • Is there a particular downside to only using the long data type?
  • Does it make sense to use for example, an int data type, instead of a long data type?
kryger
  • 12,906
  • 8
  • 44
  • 65
Robert Tossly
  • 613
  • 1
  • 6
  • 14
  • 1
    Speed, efficiency and RAM/disk space used to be at a premium so we used to worry about these things. These days on the server and desktop I see little point in it. It is probably still important in mobile apps. – Paul Tomblin Sep 16 '15 at 12:14
  • That is pretty cool, to know that in the past, these data types were more "significant". Not to say that now a days data types are not significant, however I can understand why it was more of an issue in the past. – Robert Tossly Sep 16 '15 at 12:16
  • @PaulTomblin It's still pretty easy to run out of memory by using a larger-than-necessary primitive data structure for some types of apps (admittedly I've mainly encountered this in solving example problems, but I can see that others may have more real-world experience with this). Also, just because a single app won't use up all / most of the memory doesn't mean a computer running many apps won't - I, for one, appreciate a small memory footprint. And if you're talking about big data, the difference between `long` and `int` could have a non-trivial monetary value attached to it. – Bernhard Barker Sep 16 '15 at 12:30

3 Answers3

7

Does it make sense to use for example, an int data type, instead of a long data type?

ABSOLUTELY YES.


MEMORY / DISK USAGE

Using only one variable or two you won't see difference of performance, but when apps grow it will increase your app speed.

Check this question for further info.

Also looking to Oracle primitive type documentation you can see some advices and the memory usage:

type    memory usage    recommended for
------- --------------- ---------------------------------------------------
byte    8-bit signed    The byte data type can be useful for saving memory in large arrays, where the memory savings actually matters.
short   16-bit signed   same as byte
int     32-bit signed   
long    64-bit          Use this data type when you need a range of values wider than those provided by int
float                   Use a float (instead of double) if you need to save memory in large arrays of floating point numbers. This data type should never be used for precise values, such as currency.

byte:

The byte data type is an 8-bit signed two's complement integer. It has a minimum value of -128 and a maximum value of 127 (inclusive). The byte data type can be useful for saving memory in large arrays, where the memory savings actually matters.

short:

The short data type is a 16-bit signed two's complement integer. It has a minimum value of -32,768 and a maximum value of 32,767 (inclusive). As with byte, the same guidelines apply: you can use a short to save memory in large arrays, in situations where the memory savings actually matters.

int:

By default, the int data type is a 32-bit signed two's complement integer, which has a minimum value of -2³¹ and a maximum value of 2³¹-1. In Java SE 8 and later, you can use the int data type to represent an unsigned 32-bit integer, which has a minimum value of 0 and a maximum value of 2³²-1.

long:

The long data type is a 64-bit two's complement integer. The signed long has a minimum value of -2⁶³ and a maximum value of 2⁶³-1. In Java SE 8 and later, you can use the long data type to represent an unsigned 64-bit long, which has a minimum value of 0 and a maximum value of 2⁶⁴-1. Use this data type when you need a range of values wider than those provided by int.

float:

The float data type is a single-precision 32-bit IEEE 754 floating point. Its range of values is beyond the scope of this discussion, but is specified in the Floating-Point Types, Formats, and Values section of the Java Language Specification. As with the recommendations for byte and short, use a float (instead of double) if you need to save memory in large arrays of floating point numbers. This data type should never be used for precise values, such as currency.


CODE READABILITY

Also, it will clarify your mind and your code, lets say, you have a variable that represents the ID of an object, this object ID will never use decimals, so, if you see in your code:

int id;

you will now for sure how this ID will look, otherwise

double id;

wont.

Also, if you see:

int quantity;
double price;

you will know quantity won't allow decimals (only full objects) but price will do... That makes your job (and others programmers will read your code) easier.

Community
  • 1
  • 1
Jordi Castilla
  • 26,609
  • 8
  • 70
  • 109
  • Ahhhh, so the sole benefit would be to increase efficiency/speed? – Robert Tossly Sep 16 '15 at 12:10
  • Why are speed/efficiency not enough of a benefit? The existence of primitive types in an otherwise Object-centric language is already a pure speed/efficiency measure. – Thilo Sep 16 '15 at 12:11
  • Don't forget the memory footprint. Especially when using big data structures like matrices. – Sebastian S Sep 16 '15 at 12:12
  • 1
    yeah .. back in the old days when memory was scarce, you would always evaluate which datatype to use. It is still very important when it comes to embedded programming, where memory is limited... – DTH Sep 16 '15 at 12:12
  • I'm sorry, but I do not recall stating that speed/efficiency is not enough of benefit. Please explain, Thilo. – Robert Tossly Sep 16 '15 at 12:13
  • 1
    @RobertTossly you're with your mind in little apps runned by big processors/ram memory... that's not real life.... if you start programming you will get bigger and bigger apps with obsolete machines and you will remember this question – Jordi Castilla Sep 16 '15 at 12:18
  • @RobertTossly check last update, code clarity is also a great benefit that will make your mind run faster when reading code – Jordi Castilla Sep 16 '15 at 12:25
  • Thank you for clearing that up for me, Jordi Castilla. – Robert Tossly Sep 16 '15 at 17:02
  • Be careful! `price` may _print_ with decimals, but it is not _stored_ with decimals. It's stored in binary, and most of the values that can be exactly represented with a finite number of decimal digits can _not_ be exactly represented by a `double`. For example, there is a `double` that is exactly equal to 0.25, but there is no `double` that is exactly equal to 0.2. Most experienced developers avoid the use of `double` for monetary values. – Solomon Slow Sep 16 '15 at 22:28
1

Apart from the Range (the min and max value that can be stored in any particular data type) there is another aspect and that is size of the variable.

You must be aware of the following too:

byte = 1 byte
short = 2 bytes
int = 4 bytes
long = 8 bytes

So using long variable means you are allocating 8 bytes of memory to it.

Something like,

long var = 1000L

does not show efficient use of memory. What if you got GBs of RAM these days does not mean we should waste it.

Simple point I want to make is, more efficient use of memory, faster will be the app.

gprathour
  • 14,813
  • 5
  • 66
  • 90
  • @JordiCastilla I din't understand your point. Can you please elaborate? – gprathour Sep 16 '15 at 12:21
  • oh no, my fault... byte uses 7 bits to store number and 1 to store signed... just from 128 to -127... you're right!!! – Jordi Castilla Sep 16 '15 at 12:27
  • 2
    But wouldn't the processor have to store each byte in a separate 64 bit memory area though? I thought that's how intel cpus worked anyway. Otherwise you have to do bitwise or operations if you want them packed tight? – LegendLength Jun 23 '17 at 13:06
0

Performance in memory need and speed would make long expensive.

However there is one other advantage of int: one too easily mixes with int subexpressions, and may loose long info when combining operations wrong. A bit shift left of 50 actually doing 18 and so on. Using only numbers with an L postfix would be one measure. Also long may serve as an overflow capture for int multiplication and other such operations, where for long detecting an overflow is all you can do.

Note that for int "all" operations of byte and short are propagating to int.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138