JAVA - Pointer Chasing - Best Practices

Question

I have seen a video of someone saying that we should be using primitives instead of objects as much as possible. The reason is that accessing an object means using a pointer and so there is an overhead.

Therefore:

if there is a class mapped with a SQL table (using JPA) with several fields being Objects because of potential null values in database (e.g: Integer instead of int)
- Should I create a mother class where Objects are replaced with primitives, when possible, using fixed values as equivalent to null in my app ? (e.g: -1 instead of null)
- The mother class being used when processing large amount of data
- And the child class mapped to the database, only used at the time of persisting data
- In the child class I could add some methods mapped to columns, like below:

@Column("MY_COLUMN")
public Integer getId() {
    // super.getIdAsInt() returns a value of type int, the primitive.
    // -1 means value not set in my app.
    Integer result = (super.getIdAsInt() == -1) ? null : super.getIdAsInt();
    return result;
}

I think this pattern could also be applied for any cases where the child class is about persisting data (into a database or an XML file, ...) and fields with null values are meaningful.

Do you think these could be best practices in order to improve performances of an application?
If not, could you give me some examples of potential drawbacks?

Thanks,

I think you're trying prematurely optimise your solution. You're using an OO language, why shouldn't you use objects? Sure there's an overhead, but unless you have a pressing need for the fastest possible result, don't worry about it, focus on solving the key problems in the best way you possibly can, if you find there is a performance issue then, the profile the code and see where you can make improvements — MadProgrammer, Apr 20 '17 at 22:07
Returning a dummy value for NULL when you mean NULL is code smell. You shouldn't imply it is NULL, you should say it is NULL. Anyone who uses getID and assumes that a non-null value is a non-null value will be in for an exciting time debugging why the object doesn't actually exist. — Compass, Apr 20 '17 at 22:11
To add to @MadProgrammer said: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. - Donald Knuth — mba12, Apr 20 '17 at 22:15
Use primitives instead of objects **when there's a negligible difference in what the code looks like**, or when there's a pressing need to optimise down to every last byte or operation (which is rarely the case). Either you're taking what that person said out of context, or that person should really, **really** **not** be making instructional programming videos. — Bernhard Barker, Apr 21 '17 at 04:13
I agree with you that I should first check if there are performance issues and then try to optimize. I think these optimizations could help when you have to deal with a really large amount of data (i.e: > 1 million of items) in a short time. So maybe the best thing to do is to test if these optimizations make a difference. But not to late in the project to avoid having to rewrite too much code. — Kris, Apr 21 '17 at 04:52

score 1 · Accepted Answer · edited May 23 '17 at 12:34

1

The benefits of using wrapper classes far outweigh any overhead implications. Objects can be used in collections, and they can be null. A NullPointerException is much easier to debug than a bug caused by an uninitialized primitive.

Furthermore, the solution you're proposing would add unnecessary complexity to your application that you and other developers won't want to have to deal with down the road.

This question is also discussed here.

edited May 23 '17 at 12:34

Community

1
1

answered Apr 20 '17 at 22:15

RaceYouAnytime

709
5
16

Thanks for your answer. Yes using a dummy value instead of null would be less intuitive. So I should preferably avoid it in an API. **However couldn't it be an argument, when designing your model classes, to not add unnecessary Object field instead of just a few primitive fields (i.e: less than three) ?** Especially when you know you will be dealing with a huga amount of data. – Kris Apr 21 '17 at 05:08

score 0 · Answer 2 · answered Apr 21 '17 at 09:15

You data get fetched from the DB and this takes orders of magnitude longer than the pointer chasing penalty. Whatever you may gain is negligible and gets offset by the cost of your getId using conditionals and allocating wrappers. Your non-trivial getter may prevent inlining and then you'll lose much more.

Avoiding wrappers may be essential in number crunching code using lots of primitives many times. For most programs, it's pretty irrelevant.

JAVA - Pointer Chasing - Best Practices

2 Answers2