Profiling and performance optimization

Question

This subject realy sucks in the CLDC/j2me world. Profiling in the emulator is useless, and on the device, you simply can't do it. System.currentTimeMillis() might give you some hits, but is the overhead of printing this (in my case to a comm port) is to large for the testet function, you are out of options... What to do then?
Well, with this topic, I would like to ask for some help om the possibilities of profiling j2me devices.
I'm currently working on a compression algorithm te compress log data. I found one that doesn't use a lot of memory and managed to incorporate it in my CLDC programme: ( It uses Arithmatic compression, got it from http://www.mandala.co.uk/biac/index.html ).
The problem is: Althouth the source is very compact and fairly simple, it still is very slow om my device (they claim it can do about 700 lines of java code/sec, but I think it is a bit more).
Solution: optimize, but how if you don't know where to start? Well, the algorithm is simple enough to have a look at it, and optimize by trail and error... luckilly I remenberd some things I leaned on a cource about image manipulation (in C).
So, next is a list of simple things you can do to to optimze your code, in sections where every byte of code executed is crucial:
- try to find out what code is executed often or takes a lot of time; look at loops and calculations.
- instead of x*2 use x<<1, instead of x/2 use x>>1, etc.
- try to manually unroll loops (you might first try out how often the loop runs to test who for to unroll it
- if the same calculation is used more than ones, just caclulate the value ones, and then just use that value in the other calculations in stread of caclulating it over and over. If those values are static, declare them static.
- if possible manually inline short functions. You might even use a preprocessor (in cobination with ant or somthing) and use macro's
- simplt try to do more with less code
- if you often devide though a fixed number, try to multiply with the inverted (thisis not always possible in j2me because only integer math is available). This is faster on most devices.
- Use array's if you have to acces lare amounts of data. Vectors and such are much slower.
- Use compiler and obfuscator to optimize and shrink your code.
Most of them are very obvious, but often you just forget about it.
Well, all in all, my compression algorithm got at fair bit faster, but it is still to slow. I guess I'm going to tweak it a little more ;)
Hope you guys can do something with it. If you have some more tips, just let me know!

Answer 1

Good day,
As I tried, there are two ways of doing printPreview.
To handle this problem, add only one page at a time.
To browse through the page use Prev Page, Nexe Page buttons in the toolbar.
1) BufferedImage - occupies memory .
Class PagePreview extends JPanel
public void paint(Graphics g) {
g.setColor(getBackground());
g.fillRect(0, 0, getWidth(), getHeight());
g.drawImage(m_img, 0, 0, this);
paintBorder(g);
This gives better performance, but consumes memory.
2) getPageGraphics in the preview panel . This occupies less memory, but re-paint the graphics everytime when paint(Graphics g) is called.
Class PagePreview extends JPanel
public void paint(Graphics g)
g.setColor(Color.white);
RepaintManager currentManager = RepaintManager.currentManager(this);
currentManager.setDoubleBufferingEnabled(false);
Graphics2D g2 = scrollPanel.getPageGraphics();
currentManager.setDoubleBufferingEnabled(true);
g2.dispose();
This addresses memory problem, but performance is better.
Is there any additional info from you?
Good Luck,
Kind Regards,
Krish