Just a minor point on floating point: On some architectures there is a penalty in terms of register save/restore if you use FPRs. Eg, they may have a flag in the invocation that indicates if an FPR is used, and if so then all are saved on certain types of calls, and on task switches. I have no idea if any of the Android platforms do this, though.
On Aug 19, 11:44 am, Amit <[email protected]> wrote: > Hi Daniel, > > There are no Java <--> JNI boundaries, except where I call the top- > level routine to do the image processing operation. Everything from > there on is in C, and the native routine returns the resultant > (filtered) image in a byte array. > > And I did look at DDMS logs (on Android target, not on emulator). But > not much I could gather from that. > > And I'll need to check out the Flyweight Java pattern -- I am doing so > right now upon reading your reply :) > > Will update upon any progress! > > Thanks, > Amit > > PS: May be unrelated, but here's an interesting couple of links (these > are related to effects of JVM -- Dalvik -- on run-time performance, > though not so much memory issues > > http://occipital.com/blog/2008/10/31/android-performance-2-loop-speed... > > http://occipital.com/blog/2008/11/02/android-performance-3-iphone-com... > > Of course, these entries are from 2008, so must be taken in that > context. Dalvik VM has improved quite a bit, there's now support for > FPU on Android. I read somewhere that FPU is enabled by default. As a > side note, I also considered that in performance measurement; I was > wondering whether to do fixed-point conversion of the code. But later > found out that FPU is enabled, and in fact you should get an exception > if you try to run floating point code on hardware without FPU. > > On Aug 19, 9:26 pm, Daniel Drozdzewski <[email protected]> > wrote: > > > On Aug 19, 4:20 pm, Amit <[email protected]> wrote: > > > > Hi Daniel, > > > > Thanks for the response. > > > > You are correct about the pitfalls of using the NDK. > > > > However, the primary reason that I am using the NDK is pretty much the > > > same as is mentioned in the NDK documentation. That is, legacy code. > > > > Well, not quite, but the thing is that I have two development > > > branches: for the PC and for the actual Android target. What I am > > > doing is that since the debugging support is better on the PC, I try > > > in new features (or algorithm optimizations) on the PC branch, and > > > then on the Android branch. What the NDK helps me to do is to > > > essentially use the same source for the Android branch. I do this by > > > restricting myself to the headers for which support is stable (libc, > > > math, etc. as documented by Google) and using #define switches for X86 > > > and ARM code. > > > > So your point is well taken, but using the NDK is helping me cut down > > > on development time. > > > > About the operations, the operations are basically filtering kind of > > > operations. But my guess is that the processor stalls are causing the > > > overall application to drag. Not in terms of responsiveness, as the > > > computation runs as separate thread (not on the UI thread). But I > > > would like the results of the processing to be available in a certain > > > time due to UX constraints. > > > > However, I will check out your suggestion about the Matrix class/ > > > package. Haven't used it before, so I'll check it out. > > > Matrix can be used in conjunction with Bitmap class to do coordinates > > transformations (perspective changes, skew, scale, ...) so no > > filtering unfortunately. > > > Thanks for explaining further the nature of the problem. I don't think > > I will be able to help (only basic graphical transformations done so > > far), but I will definately keep eye on this thread as it is very > > intresesting. > > The only things that I can think of now are: > > - Are you calling native code with each iteration, or is the whole of > > that loop in native code? Crossing Java <-> JNI boundaries costs time. > > - Also did you look at DDMS for memory alocations and garbage > > collections on both emulator and the actual platform? With any > > alocations within the loop and the number of pixels in a modest > > picture, it will cost. > > - Lastly: would you find use for Flyweight Java pattern that avoids > > exactly allocations/dealocations? > > > Good luck and please keep us posted! > > > Daniel -- 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] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
