As I indicated earlier, the speed of such a scheme does depend (a lot) on how well instance field access is implemented. In an interpreter, the canonical scheme is to remove from the bytecodes the field reference operation that references a constant pool entry for the field, and replace that with an operation that directly contains the offset of the field within the object. If this is done then the field reference is about as fast as you could accomplish in an interpreter.
In a JIT generally the equivalent thing is done. But you run into problems when the class being referenced isn't (fully) "known" to the JIT at the time the method is JITed. (This can happen more often than one might suspect.) If you fall into one of these oddball cases you can get burned. On Oct 7, 2:16 pm, webmonkey <[email protected]> wrote: > I am asking because I am converting a C library that uses a lot > functions that return a simple struct with primitive data type > ( Points, Sizes, Matrices, etc ) There are a lot of these functions > and some are used in performance critical situations. I would like to > know what the most efficient way is for Android > > The functions would be called like this: > > float [] size = bestSize( new float[2] ) > > or > > Size size = bestSize( new Size() ); > > ( If you are in a loop or something you only have to allocate the > object ( or array ) once and you can reuse it. ) > > I have to make a decision on what I will be using, arrays or final > classes. > > On Oct 7, 8:06 pm, MB <[email protected]> wrote: > > > In the 'Size' approach, wouldn't there have to be a NullPointerCheck > > in place of the ArrayBoundsCheck? > > > I usually use the 'Size' approach when the return values are Object > > types and 'array[]' approach for primitive data types. > > I never really thought of these from a performance perspective. Please > > do share your findings if you do any experiments etc. > > > On Oct 7, 9:35 am, DanH <[email protected]> wrote: > > > > With a fully optimized JIT they'd be identical. With a "dumb" JIT or > > > interpretive code I'd guess that the Size approach would have a slight > > > edge (no need to check array bounds, et al), but it's hard to say with > > > any certainty. (A lot depends on how well optimized instance field > > > access is, and there's potential for a 100:1 variation there.) > > > > In any event, the amount of time difference you're talking about is > > > negligible compared to many other operations that go on inside a > > > typical Android application. A single tweak of a single character on > > > the display would be thousands of times greater. > > > > On Oct 7, 10:34 am, webmonkey <[email protected]> wrote: > > > > > Taking into account JIT and non-JIT devices, what would be most > > > > efficient on Android for returning multiple values from functions: > > > > > an array like this: > > > > > float[] bestSize(float [] result) { > > > > > // calculations... > > > > > result[0] = width; > > > > result[1] = height; > > > > return result; > > > > > } > > > > > or a final class like this: > > > > > Size bestSize(Size result) { > > > > > // calculations... > > > > > result.width = width; > > > > result.height = height; > > > > return result; > > > > > } > > > > > Where Size is defined as: > > > > > public final class Size { > > > > public float width; > > > > public float height; > > > > > } -- 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
