Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 557 Vote(s) - 3.43 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Which one to use, int or Integer

#1
I need to create a data transfer object, which I will use for storing the records retrieved from database. In this data transfer object, I need to declare a numeric field. For that which one is better - **int** or **Integer**

If I am defining the field as Integer, will there be any performance impact because of 'Integer' type if I am going to retrieve more than 2000 records from DB!?

Thanks in advance.
Reply

#2
`Integer` is theoretically slower than `int`, however the performance impact should be minimal unless you are crunching numbers. Also JIT optimizations will reduce the performance loss.

Use the one that better suits your situation in terms of primitive or reference type.
Reply

#3
I guess it depends among other things on what you are using for accessing the database. With plain old JDBC you could do with `int`s, while an ORM could silently convert them to `Integers` anyway. And Integer would allow you to handle _nulls_.
Reply

#4
To my mind, the choice between declaring something as int or Integer simply comes down to whether null is a valid value for it or not. Autoboxing (and autounboxing) will take care of any conversion issues where the number simply must be one type or another. Performance (as has been pointed out) is also unlikely to be noticable in almost all cases.

Besides, int should be the natural choice, and is likely to be the most performant should that be an issue anyway. If you need to be able to store nulls, then you **have** to use Integer (and also ensure that no null references are auto-unboxed for a method that takes simply ints as this will result in a NullPointerException).
Reply

#5
To give you an idea, 2000 Integer would add about 0.5 ms to you query. If you have to serialize this data it could add quite a bit more.

However, correctness should come first. There is no point being very fast but wrong. You have to consider null values and how you handle them. (Unless the column is NOT NULL) You could use Integer.MIN___VALUE or you could use a *long* field instead of int and use Long.MIN_VALUE for null. Even though it is larger than int, it would still be many times smaller and more efficient than Integer.
Reply

#6
int is 10x faster than integer

we test this code with jetm performance library

int n;
EtmPoint point1 = etmMonitor.createPoint("test:objects");
for (n = 0; n < 1000000; n++) {
Integer t = 0;
t = 10;
t = 11;
}

point1.collect();
EtmPoint point = etmMonitor.createPoint("test:primitives");
for (n = 0; n < 1000000; n++) {
int t = 0;
t = 10;
t = 11;
}
point.collect();

etmMonitor.render(new SimpleTextRenderer());


and the results:<br/>
test:objects 10.184<br/>
test:primitives 1.151





Reply

#7
`int` can't be cast to the `String` with using the `toString` or `(String)`.

`Integer` can cast to `String` with `toString` or `(String)` and it can handle `null`.
Reply

#8
You should really make your decision based on- what you need your object to do, rather than the performance costs. Deciding based on performance should be done, once a speed issue has been identified with a profiler - the root of all evil and all that.

Look at some of the features of both and use that for your decision, e.g.

- `Integer` can be `null`, `int` cannot. So is the `int` in the *DB* a `Nullable` field?
- Do you need access to the `Integer` class methods?
- Are you doing arithmetic?

Personally, I always opt for the primitive over the wrapper. But that's just a preference thing, rather than based on any technical merit.
Reply

#9
`Integer` is a better option, as it can handle `null`; for `int`, `null` would become `0`, silently, if `resultSet.getInt(..)` is used. Otherwise, it might throw some exception, something like, "Unable to set `null` to a primitive property".

Performance is of little concern here.

- if you choose `int`, you will end-up adding extra handling code; and that wouldn't benefit you much. Your code will not be clean and straight-forward, lot of boiler-plate code, and you wouldn't even gain performance.
- let me make it clear, for databases, null is not same as zero. Sometimes you end-up entering `0`, where `null` was intended. Imagine the case where user submitted a form, and doesn't supply any value for `int`. You will end up getting `0` by default. It makes sense, or does that really, when that field is `not null` in the database.
Reply

#10
If you want to check for a `null` value then `Integer` is best but if you want to compare the integer then int may be better. In the following example I am using integer c= 1000 and d= 1000 and compare it return false but in case of int they will return true.

public class IntegerCompare {

public static void main(String[] args) {
int a = 1000;
int b = 1000;

Integer c = 1000;
Integer d = 1000;

if (a == b) {
System.out.println("int Value Equals");

}
if (c == d) {
System.out.println("Integer value Equals");

} else {

System.out.println("Integer Value Not Equals");
}
}
}

Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through