The emulator depends greatly on the performance of your local machine and does not reflect at all the actual performance on a real device.
On Thu, Apr 10, 2008 at 3:31 PM, qvark <[EMAIL PROTECTED]> wrote: > > 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. > > > -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
