java and mysql are always slowly, and you better keep your sql commands simple. "ORDER BY id DESC LIMIT 1" is pretty hard to perform on old machines. another increase in performance will be reached if you dont make loops with less than 10 items. your prof will tell you your code looks crappy but even if you write 10 times the same line, it will run faster ..

coldarchon wrote on Apr 15^th, 2010, 5:05am:

It was true with 8bit computers running Basic programs or even assembly code at 1MHz...
I doubt you will get a measurable improvement with Java on modern computers with such trick...

@posiXtom: "I would like to load pictures from a Mysql database."
I believe it is basically a bad idea...
It will bloat your database, complicate your code (you have to convert bytes to PImage) and so on. I don't see any advantage to this over storing image names (or paths) and loading by traditional means (but if you have good arguments, I am ready to hear).

oh and to the rest:

I don't think it's the mysql thing slowing it down. although it might give a quirk in the beginning when your connection is bad, than everything is loaded and you don't need the mysql connection anymore.

the problem is situated in updating the screen. i guess it's the graphic processor of the UMPC that can't handle the png or something...
just guessing here though...

It has a perfect response rate on my laptop, but slacks on the umpc

How come it looks like every one of your Update methods calls background()?

background is fairly slow and the P2D renderer is also somewhat slow, only a bit ahead of the JAVA2D renderer (default)

Any chance the UMPC supports the OpenGL renderer?

Otherwise I've found the P3D renderer to actually be faster than P2D in many cases, even for 2D.

Also I still see some printf's in there. Those calls are very slow as well. Best bet is to create your own log(String) function to call instead of printf, then before exporting just comment out the println line inside your log function and you'll save the cost of calling printf all those times, and still have all your logging functionality.

Otherwise, I really suggest cleaning up your indentation. As you continue to grow as a programmer the patterns you recognize will become more based on whitespace. You'll find it helps you follow the code much more quickly. (If the code isn't missaligned for you, perhaps you have a mixture of tabs and spaces for indenting -- I currently use spaces in place of tabs at 2 spaces per indent)

Anyways, if you really want to figure out where the app is spending it's time, start in your draw loop and store millis() in integers before and after each function call. Get the difference between the two values and you have roughly the number of milliseconds each call takes. Find the one that takes the longest, and continue down that path until you can find what really needs to be optimized.

It may come down to you're just using too much memory for the device, or you're allocating too much each frame, which will cause the garbage collector to start slowing down your app after some time. If this seems to be the case, then you just need to make sure that everything you're loading and allocating you do as much as possible in setup (or functions called from setup), and then never release all of your references to those objects so they persist for the lifetime of your app. And certainly don't load images every frame (But I didn't see any evidence of this)

Hope some of those tips help,

Jack