【问题标题】:Is It Worth Using Bitwise Operators In Methods?在方法中使用位运算符是否值得?
【发布时间】:2012-08-23 11:12:51
【问题描述】:

我对 Java 非常陌生(一般来说,我以前的经验是使用 ActionScript 2.0 和一些简单的 JavaScript),并且我正在通过 Herbert Schildt 的 Java: A Beginner's Guide 缓慢而有条不紊地工作。这是一本令人难以置信的书。

一方面,我终于或多或少地了解了位运算符(我在 ActionScript 2.0 中第一次遇到)的作用,并且对于某些总和,它们比其他方法更有效。

我的问题是,在一个有很多计算的大型程序中使用一种方法是否更有效,比如右移,为您执行所有除法/2(或除法/偶数)(在这种情况下,一个庞大的 RPG),还是简单地使用标准数学运算更有效,因为编译器会为您优化它?

或者,我是否完全问错了问题?

【问题讨论】:

标签: java optimization bitwise-operators


【解决方案1】:

一方面,我终于或多或少地理解了按位 运算符(我在 ActionScript 2.0 中第一次遇到)会这样做,而且 对于某些金额,它们比其他方法更有效。

不,这是错误的。位运算有更多的应用程序来执行您询问的除法或乘法。
您可以有效地将位掩码用作标志、打包值、以紧凑的方式模拟访问权限、在密码学等中。
看到这个thread. 您应该搜索更多的应用程序,而不仅仅是阅读关于移位如何相似并且(可能)比除法更快(不一定因为编译器无论如何都会转换为移位)的章节

【讨论】:

  • 嗨,是的,我在搜索其他用途时阅读了有关位运算符的其他一些应用。他们目前有点超出我的范围,没有双关语的意思。该部门只是作为一个例子。
【解决方案2】:

你完全问错了问题。你应该问的问题是“我应该保持我的代码简单易读,还是使用我认为可以提高其性能的技巧,即使我没有测量它的性能。”答案应该是显而易见的。

位运算符有它们的位置,尤其是当您处理需要将大量数据打包到小空间中的二进制文件格式时。知道如何屏蔽字节的高位是绝对关键的,这样您就不会意外地进行符号扩展(打印出这两个变量以了解我的意思):

byte b = (byte)0xDC;
int  i = b & 0xFF;

但是不要去寻找使用这些运算符的地方,尤其是代替除以 2 之类的简单任务。

【讨论】:

  • 感谢您的回答。这正是我一直在寻找的,它以一种简单易懂的方式解释了它。聪明的把戏很容易给我留下深刻的印象,有时让我明白聪明的把戏通常是坏事是一个飞跃。
【解决方案3】:

通常编译器会做很多优化。此外,您还需要在优化它之前调查您的瓶颈到底是什么。优化不是瓶颈的东西只会导致更多线程更快地达到真正的瓶颈。查找约束理论。

【讨论】:

  • 感谢您的提示,我在输入此内容时正在查找约束理论。
  • @user1626141:是的,现在用谷歌搜索,它看起来不像我想象的那么直接相关。真正重要的是在优化之前先进行测量,这样你就知道你正在改进关键路径上的东西。仅仅因为你可以优化一切几乎总是浪费时间,或者实际上是可能的性能问题的根源。然后当然还有你在代码库中引入的肮脏。小玩意儿很有趣,而且有它的用武之地,只要确保你进行一些测量以确保它是合理的。
【解决方案4】:

出于学习目的,您可以跳过以这种方式优化您的代码。它需要一些经验,否则您可能会在调试代码时遇到问题(我的主要意思是“这东西到底在做什么?”综合症)现在的编译器足够聪明,可以优化输出代码并以正确的方式处理已知模式。除非您真的需要节省每个毫秒或 cpu 周期,否则请专注于保持代码清洁。

【讨论】:

  • 谢谢你的建议,我怀疑我需要每毫秒保存一次!它是干净的代码。无论如何,这就是我喜欢编码的原因,清晰。
  • 我喜欢你的方法。你会在这项业务中取得好成绩:)
【解决方案5】:

后者。也就是说,首先以最清晰的方式编写代码,这很可能需要标准的数学运算。让编译器处理剩下的事情。

Java,因为它在 VM 上运行,所以它具有其他有趣的内置优化功能:例如,当您的程序运行时,VM 可以查看哪些代码分支执行得最频繁,并提高这些分支的效率。

编写程序后,请使用分析工具来衡量哪些特定方法速度较慢。一旦你知道了这一点,那么你就会知道要优化什么样的代码。例如,您可能会发现从文件中读取配置是您做的最慢的事情,您可以寻找方法来加快速度。我的直觉是,使用位运算符之类的东西而不是普通的算术,你根本不可能发现任何性能优势。

祝你好运!

【讨论】:

  • 感谢您祝我好运,我很感激 :) 只有在我的程序正常运行后,我才会考虑使用分析工具。
【解决方案6】:

只有在您真正需要时才应进行此类优化。如果您只是认为代码会运行得更快,那可能不值得。

通常编译器可能比您想象的更聪明,并且会为您进行优化,其他时候可能会有一些警告,只会让您陷入更深的麻烦。最重要的是(可能是反对这样做的最大原因),如果它使您的代码难以被未来的开发人员(或您自己)阅读/理解,那么您可能只会在将来尝试工作时添加更多的反优化围绕原始代码。

【讨论】:

  • 干杯!我不想让其他开发人员难以阅读或理解我的代码。我喜欢您关于使您陷入困境的警告的观点,不仅要学习语言,还要学习计算机,我可以很容易地想象每次“改进”都会遇到数百个技术问题。
  • 您的代码将始终被两个人阅读:您自己,然后是 6 个月后的您自己。
猜你喜欢
  • 2015-09-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-09-22
  • 1970-01-01
  • 2012-09-27
  • 2011-02-11
相关资源
最近更新 更多