Hi, Thanks for the response.
I apologize if I was vague or confusing. My question actually was on two issues, and I guess I mixed them up. The FIRST is of course code performance. And there in the comments about efficacy of native code at improving performance, etc. But the SECOND, and more important thing that I am trying to get a handle on, is about *memory related performance issues*. What I mean by that is, that as on any embedded system, processor stalls due to cache misses, page swapping would play a big role in performance. That is, let us say that a certain code (whether in Java or native code) takes a certain cycles on a cycle accurate simulator. And let us say that the simulator does not give us memory stalls. The difference between the profile on such a cycle-accurate simulator and actual profile (on the embedded system) would be the memory stalls. My question is if I can find resources that help me to optimize for memory. That is, are there certain 'best practices' when it comes to developing applications for image processing algorithms on Android (whether in Java or native code)? On Aug 19, 5:54 pm, Fabrizio Giudici <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/19/10 14:33 , Amit wrote: > > > Well yes, I only meant that just the fact of using native code > > (over Java) won't be very effective. At least that is the > > impression I have (which may be wrong). > > > Considering the fact that even native code ultimately runs inside > > the Dalvik VM instance, performance gains from use of native code > > would be modest, right? > > Things are a bit different. As far as I understand, applications in > general only run inside the Dalvik VM - which means that e.g. > activities, boot code etc... is bytecode. In other words, a 100% > native app can't exist in Android. But the NDK allows you to create > portions of native code that are called by the app. That is, a flow of > operations is always started by the VM, but your native code gets > executed directly on the processor. This is more or less the same that > happens with JNI in the regular Java JDK. > > Given that, before moving to native code I'd wait for others to share > with you their experience specifically with image processing. > > PS It's a shame that Google dropped some imaging back-end classes from > Harmony, as there are a number of powerful and complete imaging > libraries in Java such as JAI. > > - -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici -www.tidalwave.it/people > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxtKYAACgkQeDweFqgUGxdg6wCgpJM/beTx9U0thsO30tjNh0Mp > lOUAnRRBs/XxM9PutV+7KOh7CoLGehE8 > =bXS+ > -----END PGP SIGNATURE----- -- 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
