关于效率,“舍不舍得”声明Java对象?

Iuranus 发布于 2013/08/09 17:14
阅读 381
收藏 0

如图,这个例子中变量确实“小”了一些。那诸如此类使用次数比较少的变量/对象,各位是按照如图声明并初始化(如图这样写看上去会清爽些),还是直接把a/b给替换了?

加载中
0
sxgkwei
sxgkwei

莫名其妙的人整天在纠结一些莫名其妙的事情。

对于现代计算机,效率问题只会因为通盘设计,整体逻辑优劣而产生出差异。至于你这个问题,那根本和效率没关系。而如果简略的命名了的话,还会导致以后/别人看代码不懂你到底想干嘛,导致理解业务逻辑困难。这不是没事找抽吗?

再补充一句:去做你该做的事情去,去想方设法解决你真实要解决的问题去,别整天纠结这些没用的。人生首先是要从大方向上着眼。

Iuranus
Iuranus
嗯,被说到痒处了~对于Java来说,业务逻辑和框架才是重点。
0
中山野鬼
中山野鬼
java的语言,这种替换不要搞,关键把业务逻辑描述清楚就好。c语言,除了统计用的浮点最后使用除法,整型原则上是杜绝除法的。即便有除法,也是替换成查表法实现。两种语言追求的目标不一样。安心把业务分析好是实在的。
Iuranus
Iuranus
各有专攻,说的在理。
0
jiuyueshouyi
jiuyueshouyi
在c/c++中,这种情况很可能就被编译器优化掉了,即使你写了,也不会产生这两个对象
Iuranus
Iuranus
底层貌似如此,之前没考虑这个,疏忽了。
0
小耶果
小耶果
拿卖白菜的钱操卖白粉的心.工作内容至少接触汇编语言,关注此类问题才有意义.最烂的编译器都会替你优化掉多余的东西.因为编译器看到的东西永远比你多.
Iuranus
Iuranus
是的,考虑这个问题没过脑子,没考虑到底层的实现。
0
m
mononite

短生命周期的对象对现在的JVM来说根本不是事,保证代码的可读性几乎永远都是第一位的,上面的代码可以写成:

float ratio = Math.max(width / STANDART_WIDTH, height / STANDART_HEIGHT);
另外,在源代码里没有显式声明变量,并不意味没有声明变量,在你的例子里,JVM不可能直接比较"width / STANDART_WIDTH"和"height / STANDART_HEIGHT"两个表达式的值。
Iuranus
Iuranus
确实如此,编译器在实现时依旧会有变量以及必要的优化。
0
南湖船老大
南湖船老大

莫名其妙的人整天在纠结一些莫名其妙的事情。

哈哈

Iuranus
Iuranus
见笑了。
0
专业打酱油
专业打酱油

1、你这个不是java意义的对象吧,你这个是基本的数据类型

2、java的对象一般指new Xxoo()

3、无论哪一中,如果出现在循环、递归等可能长期持有或运算的情况下,需要考虑变量或对象的生命周期。

4、你这个例子的话,无论如何写,都没有错误,我可能会去掉a,b,因为这个逻辑比较简单,而且简短不拖沓。

5、需要注意的是保证业务代码正确的前提下,尽量保证可读性。

6、不要为了优化而优化

Iuranus
Iuranus
嗯,对象还是清楚的。看了各位的回复,知道了许多,谢谢。
返回顶部
顶部