大部分的书在讲解涉及到性能优化的时候都告诉我们不要过早优化。简而言之,过早优化是万恶之源。
过早的担心性能问题,不经过性能测试,同时花费大量的时间和精力去在一些主观判断的性能瓶颈点做了一些性能优化的工作,实际上很有可能对性能提高没有什么帮助,而且导致代码可读性直线下降。这样的做法当然是不明智的。
但是,打着过早优化是万恶之源的幌子,从而在写代码的时候压根不考虑性能问题,以为计算机就是万能机器,没有性能问题,一样是不可取的。
在写code的时候,性能还是应该有所考虑的。而且很多时候,对性能问题的考虑并不会花费很多时间,同时也不会把代码搞的一团糟。
上面的code判断了一个用户是本月的非第一次登录,或者是一个受保护的用户,是的话返回true,做一些处理。
大眼一看,这段代码当然是没有什么问题的。但是加上性能的考量,问题就出来了。
isLoginAgainInMonth是一个local call,isGardUser是一个ws call,当isLoginAgainInMonth为true的时候是可以直接返回的,多调用一次isGardUser就多一次ws开销,这个开销包括网络开销,内存开销,甚至db开销。如果该代码被大量执行次数放大的话,所消耗的资源还是很可观的。
这里调整代码来强调方法的调用顺序对性能的影响。重构后为:
还有一种利用短路特性的写法。
这种写法利用短路的特性达到了同样的功能,并且看上去代码更简洁。
但是,应该承认的是,并不是所有程序员对短路的特性都掌握了,同时,即使掌握短路的程序员看到这段代码的时候也未必能够意识到这里的短路和性能相关。该写法没有达到强调方法调用顺序和性能的关系的作用,因此不推荐这种写法。
过早的担心性能问题,不经过性能测试,同时花费大量的时间和精力去在一些主观判断的性能瓶颈点做了一些性能优化的工作,实际上很有可能对性能提高没有什么帮助,而且导致代码可读性直线下降。这样的做法当然是不明智的。
但是,打着过早优化是万恶之源的幌子,从而在写代码的时候压根不考虑性能问题,以为计算机就是万能机器,没有性能问题,一样是不可取的。
在写code的时候,性能还是应该有所考虑的。而且很多时候,对性能问题的考虑并不会花费很多时间,同时也不会把代码搞的一团糟。
public boolean f_0(String userId) {
// isLoginAgainInMonth is local call.
boolean isLoginAgainInMonth = isLoginAgainInMonth(userId);
// isGardUser is ws call.
boolean isGardUser = isGardUser(userId);
return isLoginAgainInMonth || isGardUser;
}
上面的code判断了一个用户是本月的非第一次登录,或者是一个受保护的用户,是的话返回true,做一些处理。
大眼一看,这段代码当然是没有什么问题的。但是加上性能的考量,问题就出来了。
isLoginAgainInMonth是一个local call,isGardUser是一个ws call,当isLoginAgainInMonth为true的时候是可以直接返回的,多调用一次isGardUser就多一次ws开销,这个开销包括网络开销,内存开销,甚至db开销。如果该代码被大量执行次数放大的话,所消耗的资源还是很可观的。
这里调整代码来强调方法的调用顺序对性能的影响。重构后为:
/**
* Note: 为了性能考量,先调用本地方法,后调用ws服务,当可以判断出结果的时候,尽早返回。
* */
public boolean f_1(String userId) {
// isLoginAgainInMonth is local call.
if (isLoginAgainInMonth(userId)) {
return true;
}
// isGardUser is ws call.
return isGardUser(userId);
}
还有一种利用短路特性的写法。
/**
* 不推荐的写法。
* */
public boolean f_2(String userId) {
return isLoginAgainInMonth(userId) || isGardUser(userId);
}
这种写法利用短路的特性达到了同样的功能,并且看上去代码更简洁。
但是,应该承认的是,并不是所有程序员对短路的特性都掌握了,同时,即使掌握短路的程序员看到这段代码的时候也未必能够意识到这里的短路和性能相关。该写法没有达到强调方法调用顺序和性能的关系的作用,因此不推荐这种写法。