Doing pixel-level processing in within the Dalvik VM will necessarily incur the overhead of copying the pixel data into the VM heap. As others have suggested, this needs be done to gain fast access to the pixel data.
But I doubt that this is the bottleneck, it's certainly the interpreted nature of the Dalvik VM. There's a useful detailed post about the overhead here: http://groups.google.com/group/android-developers/browse_frm/thread/60e00ab2de9abb2d/9ee69bafad211e87#9ee69bafad211e87 If my understanding is correct, this means that an operation like an integer add costs 1 CPU cycle, but the VM adds an overhead of approximately 20 cycles to every instruction, so code which has a performs a large number of fast operations (such as image processing) is going to be very badly penalized. To put this more clearly, lets hypothesize that a method call takes 20 CPU cycles (I've plucked that figure out of mid-air) then the interpreter overhead means that an integer add is only twice as fast as a method call. This is going to skew performance characteristics dramatically away from the norms that developers expect. But I think there are reasons to be hopeful. In this post, Dan Morrill indicates that "a just-in-time compiler is definitely on the Dalvik roadmap": http://groups.google.com/group/android-developers/browse_frm/thread/c4a8b4d97f408b17/6574e60b4add1fc4 I don't know where on the roadmap, that might be. Also the potential benefits of a JIT are probably very difficult to prejudge (due to issues that are beyond my experience, such as cache considerations). Nevertheless I did a very quick analysis using the data here: http://shootout.alioth.debian.org/ I compared, Sun's interpreter against Sun's hotspot compiler and chose the median of the execution-time ratios. This (totally ridiculous) procedure gave me a figure of about 8x speed improvement (of course this figure will differ dramatically based on the application and many other factors). It was just a very quick way to get an estimate without actually needing to write an AOT or JIT compiler which would be the only reliable way. I've gone a bit off topic, but I just thought some background might help. Tom. On Mar 30, 12:19 pm, saurabh <[EMAIL PROTECTED]> wrote: > Hi, > > I am working on an image processing application. The job is simple: > > 1. read an image into a Bitmap object A, > 2. create a new Bitmap object B of the same dimensions, > 3. iterate over Bitmap A examining each pixel and copying it to B if > it satisfies some conditions, > 4. display Bitmap B using ImageView. > > The trouble is that though the application is working correctly, it is > too slow to use. For a JPEG image of 547x450 resolution, the > application takes 66 seconds to produce the final output. The getPixel > function seems to be taking approx 1/100 of a second. Similarly, > checking whether each pixel satisfies the condition and then copying > it to Bitmap B also takes approx 1/100 second. Therefore, performing > these 2 operations for 547*450 = 246150 pixels takes a lot of time. Is > there any way to do this faster? I hope to use this for processing > each frame of a video in real-time. So, processing each picture must > not take more than a 1/20 of a second. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
