Using 'Number' class instead of primitives on a game? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

Right now, I'm developing a heavy 2D game write in java+LWJGL (ok, it could have looked funny when I said "heavy 2D game", but trust me, I'll be using LOTS of resources), and, well, let's say I have TOC (TOC is in Brazil, maybe in english it's... OCD?), so I have to write, for everything I'll use third-party, an API. Like, I have an API for LWJGL (an API for an API of OpenGL, lol), and a lot of other API classes. And, inside these APIs, on constructors, I never use primitives (constructors only, fields I still use primitives), but instead I use Number class (so I can call the methods using Integer, Float, Double, and whatever I want). Then, inside the constructor, I translate the number, using number.doubleValue() or number.intValue(), depending on what I want.

So, do this can affect dramatically the performance of my game? Until now, in the early-middle development stage, my performance is still OK but I'm worried of it causing me to re-write most part of the code late. Oh, and sorry for my soo bad english, it's not my primary language.

Answer 1

Don't use boxed primitives unless you really need them. A good reasons may be

• you need an representation for the undefined state (use null)
• you put them into Object-accepting classes (List, Set, Map, ...) and want to avoid boxing (by working with boxed values all the time)

Anything performance-related must be benchmarked first, otherwise you can find yourself optimizing a piece of program taking no measurable time or even "pessimizing" it. Low-level optimizations in Java are pretty hard, so you'd better concentrate on clarity and readability, so you can measure the speed, identify the bottlenecks, and optimize them afterwards.

Concerning boxed primitives, IMHO the biggest performance impact doesn't come from object creation but from the indirection (creation happens once, repeated cache misses are costly).

I disagree with dognose concerning the "fancy OOP stuff". Everything the classes offer can be used without boxing and working with boxed primitives is a pain the OOP methods can't ever make good (the unexpected NullPointerExceptions, non-working conversions, etc. are IMHO too bad).