Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
New Developer
KevinMontrose
Posts: 4
Registered: ‎01-03-2009
My Device: Not Specified

Aggressive Optimization

I'm working on porting over a very* resource intensive game/application from generic J2ME to a 8330 (4.5.0.77), using BlackBerry specific features
to improve performace and usability.

I've gotten its performance to "painfully playable" by making more intelligent use of image data; mostly replacing Image with Bitmap and pre-allocating and reusing those religiously, along with skipping "unneccisary" screen updates. Most of the application time is spent doing serious number crunching; there is significant access to fairly large byte arrays as well.

My questions boils down to: What are some tips for optimizing applications in general and math/memory access in particular?

Things I'm working on:
-replacing all division with shifts or subtler tricks
-more intelligent partial updates of the main screen (finer grained than a single box around all changes frame-to-frame)
-aggressively re-using objects

Things I've considered, but am not sure will help:
-packing byte[] into int[] and unpacking as necessary; is it faster to operate on int[] vs byte[]? Enough to overcome unpacking costs?

Any additional ideas and observations greatly appreciated.

*For a mobile application

Developer
Posts: 5,339
Registered: ‎09-20-2008
My Device: ***
My Carrier: ***

Re: Aggressive Optimization

int is processing faster than byte

and int[] is processing faster than byte[]

 

Check the link below to get answers to your questions:

 

http://www.javaperformancetuning.com/tips/j2me.shtml

Developer
marchywka
Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Aggressive Optimization

I used to work at Eyewonder when we had a java multimedia applet for delivering ads to browsers, and I spent a lot of time optimizing code for both size and speed ( this, along with preventing browser hangs,  reduced the number of death threats we got so it was quite important, LOL).

 

Anyway, there are at least two things to keep in mind- the run time environment and the underlying NATIVE architecture. And, never ignore empirical results as obvious things don't always work. For example,

I'm not entirely sure what the issue with int[] versus byte[] entails as certainly doing things in native

bus size increments can be helpful but on desktop systems with caches the 4x change in size can make

cache misses a huge problem ( even on the c++ lists, people tend to ignore this issue).

 

Looking at the link you provide, and remembering as best I can, sure we did many of these things including loading tables from IIRC a string ( there turned out to be something like an automatic 2x size reduction in addition to whatever compression you could get from clever string encoding ) but if you dig through jad output

( decompiled code) or a class inspector, or just use dump the binary class files, it is easy to figure out size. Speed is more confusing as it depends on at least the two machines mentioned above.

 

I also would suggest stepping though a few system calls too- these are often designed as various compromises ( and of course most jre's can't inline/compile too well ) and I did just note the RIM GUI components are a bit OCD about checking "do I have the event lock" etc. Sometimes inheriting ( make more calls ) isn't always a good way to go

if you need a certain type of optimization and can give up something like a false sense of security.

 

Anything CPU  intensive is going to be a trick in java. The "portable to the last bit" requirement usually means all floating point is software emulated. Divisions are always bad on most FPU's but remember that bit shifts may not execute as a single native instruction either.

 

 

 

 

 

 

 

 

 

New Developer
KevinMontrose
Posts: 4
Registered: ‎01-03-2009
My Device: Not Specified

Re: Aggressive Optimization

To clarify a bit.  I'm looking to optimize solely for speed, size doesn't matter much (this app is for use by a very few people, so distribution etc. isn't a concern).  Provided that the size doesn't balloon to "ridiculous", any space-time trade-offs are fine.

As for int[] vs byte[]*, I think I'm justing going to go and build a small test application for some benchmarking; I'll report the results.  My biggest concern is that &'ing and >>'ing the data out will erase any gains made by operating on data in word units.

I also have no problem living dangerously; if there's some way to  jetison some of the GUI cruft in the name of efficiency, I'm all ears.  My current model is extending a FullScreen, invaldiating changed regions (roughly, some optimization to "change detection" is underway), and then  blitting an image into those regions in the resultant paint(Graphics) call.

*To further clarify, I'm propsing converting a byte[4*n] into a int[n] and making the lookup a little complex (but not inefficient, I hope).
Developer
jonberry
Posts: 484
Registered: ‎07-17-2008
My Device: Not Specified

Re: Aggressive Optimization

Are you saying the performance was better a generic J2ME app?

 

If there aren't that many users, why not port it to the Bold?

 

The CPU has got to be much more powerful.

New Developer
KevinMontrose
Posts: 4
Registered: ‎01-03-2009
My Device: Not Specified

Re: Aggressive Optimization

Performance has improved by using Bitmap/Fullscreen (versus the J2ME Canvas and Image used in the original).  Its still undesirably slow though, though I'd estimate its two to four times as fast as the original.  I attribute most of the speed gains to object re-use.

Although this app is only intended for a few users, the phones are fixed.  The low end is the aforementioned 8330, and is infact the model I'm using for testing (in addition to the simulator, of course).  I do agree that moving to an even moderately faster model would solve the speed issues, but that's not an option unfortunately.
Developer
Posts: 5,339
Registered: ‎09-20-2008
My Device: ***
My Carrier: ***

Re: Aggressive Optimization

Check this article:

 

J2ME Game Optimization Secrets

New Developer
KevinMontrose
Posts: 4
Registered: ‎01-03-2009
My Device: Not Specified

Re: Aggressive Optimization

Thanks for the links; I'll see what I can apply from them.

As promised I ran some tests with int[] versus byte[] access.  With the &&'ing and >>'ing required to put the data in the same space int[] is much slower than byte[]; straight replacing byte[] with int[] looks like a wash.
BlackBerry Development Advisor
MSohm
Posts: 14,753
Registered: ‎07-09-2008
My Device: BlackBerry Passport

Re: Aggressive Optimization

Here are some links that discuss optimizing code for BlackBerry handhelds.

 

http://na.blackberry.com/eng/devjournals/resources/journals/may_2004/java_bits.jsp

 

http://na.blackberry.com/eng/devjournals/resources/journals/oct_2004/java_bits.jsp

 

http://na.blackberry.com/eng/devjournals/resources/journals/jan_2005/java_bits.jsp

 

http://na.blackberry.com/eng/devjournals/resources/journals/jan_2006/direct_screen_drawing.jsp

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
BlackBerry Development Advisor
MSohm
Posts: 14,753
Registered: ‎07-09-2008
My Device: BlackBerry Passport

Re: Aggressive Optimization