This article applies to BlackBerry® wireless devices based on Java™.
Timing is very important for some applications, such as games. Since time comparisons in these types of applications normally span a period no longer than a few seconds, you can downcast the
long from a date to an
integer as a possible optimization strategy.
long is normally obtained via a call to
System.currentTimeMillis(). Regardless of how the date is represented as a
long, if the time frame of the comparisons is less than 24.85 days (i.e., 231 -1 milliseconds), then the contents of the first 32 bits of the
long can be dropped by converting the
long to an
int. This conversion saves four bytes per instance.
Be cautious when performing this optimization. Approximately every 24.85 days, the 32nd bit of the
long will be set to the value
1 and will remain so for approximately another 24.85 days (i.e., until the value of the first 32 bits doubles, thus pushing the
1 into the 33rd bit). The pitfall of having the 32nd bit set to
1 is that since this is the lead bit of the resulting
int should be interpreted as negative. This negative number will throw off timing calculations since it is expected that the next point in time is greater than the previous.
To counter this problem, you can refrain from using this optimization, or use
ints whenever the casting yields a positive value and use
longs whenever the casting yields a negative value.
You are recommended (unless the application is under extreme space limitations) to not use the optimization strategy outlined in this document. With the minimal space savings and the extra computations (the casting, the comparison, and the possible re-assignment), the benefits of this optimization do not necessarily outweigh the added complexity.