on a G1, adding two floats takes about 400ns. adding two ints takes about 250ns.
on a nexus one running eclair (pre-JIT), both operations take around 120ns. (ints are slightly faster, but you'd have to be microbenchmarking to notice.) there's a small percentage difference between int and long, and float and double, but basically if you can afford one, you can probably afford the other.
other current devices will be somewhere between these extremes. (other operations will differ too. multiplication is more expensive than addition/subtraction, and division is more expensive still. no current devices have hardware integer division.)
but don't obsess about any of this until you have a problem. chances are, your performance problems will be down to a poor choice of algorithm or data structure, just like everyone's performance problems always are.
most of the current (eclair) performance documentation is incorrect. benchmark things yourself, on the device(s) you care about.
but if you were really asking "what should a desktop/server java programmer watch out for?", i'd suggest: unnecessary allocation. you don't have a spare core to do your GC like you do on the desktop/server, and you don't have gigabytes of heap like you do on the desktop/server. if you're doing GC, you're not doing real work, and your heap will be at most 24MiB on current devices. so you might want to avoid unnecessary allocation in inner loops.
很多人还说避免使用对象，在手机速度很慢和 java me 的时代，人们习惯用静态函数编写 java 程序。但我现在不建议这样做。
The reason they want you to avoid using float is because it's rarely implemented on phone cpu's(Probbly arm), and has to be implemented in software which is slow. Fixed point is usally surported in hardware although.
Some phones do implement floating point in hardware, but since you don't what phone your app might be deployed to they don't risk it.
A lot of people also say avoid using objects, back in the days of really slow phones and java me people used to write java procedurally with static functions. I would not recommend that now though.
Don't worry about performance until you know the code has major issues. The little tweaks (ints instead of floats, using iterators instead of explict array enumeration) tend to be really minor and you are better off looking at them when your app is down. Make the 5% of the code that is slow more complex rather than making the whole app.
ArrayList<String> strings = new ArrayList<String>();
According to the Android folks, you should avoid using the Interface names for collections. For instance, the standard best practice for standard Java would be to say
List<String> strings = new ArrayList<String>();
Whereas in Android they say it's better to declare it with its runtime type
ArrayList<String> strings = new ArrayList<String>();
I have found that the AppInventor emulator is extremely slow for floating point ops, even on a 2014 i3/4Gb machine. I wrote a fractal generator to benchmark the emulator and found that to calculate a single pixel, to 10 iterations took just over two seconds - yes, 2,000ms. I haven't fully unpicked it to find which particular operations are so slow but I will be doing that soon.
Each iteration involves four multiplications, two additions and one subtraction, five variables. Testing after each iteration involves two multiplications, one addition and two comparisons - roughly 30 flops. I haven't yet optimised the code by storing results for the next iteration.
Clearly, if there is a way to force fixed point or to use integers only that would help, but the magnitude of the problem I faced with this tiny project is not a good omen.
发布评论
评论（6）
关于浮点：
在 G1 上，添加两个浮点大约需要 400ns。两个整数相加大约需要 250 纳秒。
在运行 eclair（JIT 之前）的 Nexus One 上，两个操作大约需要 120 纳秒。 （int 稍快一些，但您必须进行微基准测试才能注意到。）int 和 long、float 和 double 之间存在很小的百分比差异，但基本上，如果您买得起其中一个，您也可能买得起另一个。
当前的其他设备将介于这两个极端之间。 （其他操作也会有所不同。乘法比加法/减法更昂贵，而除法仍然更昂贵。当前的设备没有硬件整数除法。）
但是在遇到问题之前不要沉迷于这些。很可能，您的性能问题将归因于算法或数据结构的错误选择，就像每个人的性能问题一样。
当前的大多数 (eclair) 性能文档都是不正确的。在您关心的设备上自行进行基准测试。
但如果你真的问“桌面/服务器java程序员应该注意什么？”，我建议：不必要的分配。你没有像在桌面/服务器上那样的备用核心来执行GC，也没有像在桌面/服务器上那样有千兆字节的堆。如果您进行 GC，那么您并没有做真正的工作，并且您的堆在当前设备上最多为 24MiB。因此您可能希望避免内部循环中不必要的分配。
wrt floating point:
on a G1, adding two floats takes about 400ns. adding two ints takes about 250ns.
on a nexus one running eclair (pre-JIT), both operations take around 120ns. (ints are slightly faster, but you'd have to be microbenchmarking to notice.) there's a small percentage difference between int and long, and float and double, but basically if you can afford one, you can probably afford the other.
other current devices will be somewhere between these extremes. (other operations will differ too. multiplication is more expensive than addition/subtraction, and division is more expensive still. no current devices have hardware integer division.)
but don't obsess about any of this until you have a problem. chances are, your performance problems will be down to a poor choice of algorithm or data structure, just like everyone's performance problems always are.
most of the current (eclair) performance documentation is incorrect. benchmark things yourself, on the device(s) you care about.
but if you were really asking "what should a desktop/server java programmer watch out for?", i'd suggest: unnecessary allocation. you don't have a spare core to do your GC like you do on the desktop/server, and you don't have gigabytes of heap like you do on the desktop/server. if you're doing GC, you're not doing real work, and your heap will be at most 24MiB on current devices. so you might want to avoid unnecessary allocation in inner loops.
有关特定于渲染的性能提示，请参阅以下 Google I/O 2009 演讲：
For rendering-specific performance tips, see these Google I/O 2009 talks:
他们希望你避免使用浮动的原因是因为它很少在手机CPU（可能是arm）上实现，并且必须在速度缓慢的软件中实现。不过，硬件通常支持定点。
有些手机确实在硬件中实现了浮点，但由于您不知道您的应用程序可能部署到什么手机上，因此他们不会冒险。
很多人还说避免使用对象，在手机速度很慢和 java me 的时代，人们习惯用静态函数编写 java 程序。但我现在不建议这样做。
The reason they want you to avoid using float is because it's rarely implemented on phone cpu's(Probbly arm), and has to be implemented in software which is slow. Fixed point is usally surported in hardware although.
Some phones do implement floating point in hardware, but since you don't what phone your app might be deployed to they don't risk it.
A lot of people also say avoid using objects, back in the days of really slow phones and java me people used to write java procedurally with static functions. I would not recommend that now though.
在您知道代码存在重大问题之前，不要担心性能。这些小调整（使用整数而不是浮点数，使用迭代器而不是显式数组枚举）往往很小，当您的应用程序关闭时，您最好查看它们。让 5% 的速度慢的代码变得更复杂，而不是让整个应用程序变得更复杂。
Don't worry about performance until you know the code has major issues. The little tweaks (ints instead of floats, using iterators instead of explict array enumeration) tend to be really minor and you are better off looking at them when your app is down. Make the 5% of the code that is slow more complex rather than making the whole app.
根据 Android 人员的说法，您应该避免使用集合的接口名称。例如，标准 Java 的标准最佳实践是说，
而在 Android 中，他们说最好使用其运行时类型来声明它
According to the Android folks, you should avoid using the Interface names for collections. For instance, the standard best practice for standard Java would be to say
Whereas in Android they say it's better to declare it with its runtime type
我发现 AppInventor 模拟器对于浮点运算来说非常慢，即使在 2014 i3/4Gb 机器上也是如此。我编写了一个分形生成器来对模拟器进行基准测试，发现计算单个像素需要 10 次迭代，只需要两秒多一点的时间 - 是的，2,000 毫秒。我还没有完全拆开它来找出哪些特定操作如此缓慢，但我很快就会这样做。
每次迭代涉及四次乘法、两次加法和一次减法、五个变量。每次迭代后的测试涉及两次乘法、一次加法和两次比较——大约 30 次失败。我尚未通过存储下一次迭代的结果来优化代码。
显然，如果有一种方法强制定点或仅使用整数会有帮助，但我在这个小项目中面临的问题的严重性并不是一个好兆头。
I have found that the AppInventor emulator is extremely slow for floating point ops, even on a 2014 i3/4Gb machine. I wrote a fractal generator to benchmark the emulator and found that to calculate a single pixel, to 10 iterations took just over two seconds - yes, 2,000ms. I haven't fully unpicked it to find which particular operations are so slow but I will be doing that soon.
Each iteration involves four multiplications, two additions and one subtraction, five variables. Testing after each iteration involves two multiplications, one addition and two comparisons - roughly 30 flops. I haven't yet optimised the code by storing results for the next iteration.
Clearly, if there is a way to force fixed point or to use integers only that would help, but the magnitude of the problem I faced with this tiny project is not a good omen.