These performance issues are being a real headache for me! My project relies very heavily into image processing algorithms, and they take too long when executing over the emulator.
The set of algorithms executed with a Sun JVM (1.6.0_03) take less than 20 secs but when I execute them within the emulator (in the same machine), they are taking over 7 minutes! That's more than 20x slower! Initially it was over 10 minutes, and I have reduced the time following the Android performance advices, but I don't think I will be able to reduce much more. I'm worried because I wanted to present my project to the ADC but with this performance the application becomes unusable. Do you think using JNI would be a solution? Most of the time is spent doing convolution operations... do you know any way to do them more efficiently in Android? Do you think the ADC judges will understand the performance issues with the emulator and the Dalvik VM and will be lenient? Thanks in advance, Jose Luis. On 2 abr, 09:18, saurabh <[EMAIL PROTECTED]> wrote: > After copying all the pixels to int[], I iterate over the int array > and check if each element satisfies a condition. I tried optimizing > the code by removing as many floating point operations and divisions > as possible. This has helped me reduced the time further by approx 5 > seconds. > > On Apr 2, 4:02 am, tomgibara <[EMAIL PROTECTED]> wrote: > > > 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/6... > > > 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/c... > > > 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 aBitmapobject A, > > > 2. create a newBitmapobject B of the same dimensions, > > > 3. iterate overBitmapA examining each pixel and copying it to B if > > > it satisfies some conditions, > > > 4. displayBitmapB using ImageView. > > > > The trouble is that though the application is working correctly, it is > > > tooslowto 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 toBitmapB 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 android-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
