and 替换 all 过程的一些感想

今天在公司论坛上看到一个性能优化贴，其中一个童鞋讲了个例子：

用 a==a and b==b 替换 all([a == a, b == b])，然后接口 P95 从 110ms 降到了 65ms

当时感觉特别神奇… 这样就可以减 50ms？于是自己做了个非常简单的 benchmarking，代码如下

import time


start = time.time()
count = 0

def func():
    # print('')
    return True


while True:
    if time.time() - start >= 1:
        print('count:', count)
        break
    count += 1
    all((True == True, True == True))  # count -> 2501950
    #all([True == True, True == True])  # count -> 2509672
    # True == True and True == True  # count -> 3819233

从结果可以看到使用 and 明显可以提速。

为啥呢？

  • 一方面， all 会全部计算，而 and 相对 lazy 一点，如果第一个条件结果为 False，那 and 后面一个判断就不会执行。
  • 另一方面， 我暂时还不知道… （all 这个应该会有函数调用或者什么的？）

对这个事情，我感受特别深，很早之前，我不知道有 all any 这种高级的东东， 某天，我在 review 他人代码时，看到这个东西，当时感觉，哇，这写法好炫酷，自那之后， 一有机会，我就会尝试用 all 和 any 来写判断，然而就在今天，这个简单的例子就像 当头棒喝（oh 耶，我成功的使用了一个成语）。

另外，我觉得上面这个性能测试的样例代码非常有启发意义（之前在看一个讲 python concurrency 的视频中看到的，我觉得这个视频应该是我写代码生涯中的第二个导师，2333）。 以前，我完全不知道该怎样写一个程序来做 benchmarking？完全没有思路的那种状态。 个人感觉它的思想特别巧妙：测试一秒钟程序能跑多少次，来测试代码性能（反正自己以前就是没想到这种方法）。

之前也用这个思想测试了下 json.load 和 pickle.load ，发现它们性能真的差好远哦，另外， json.loads 一个大的 str 和 一个小 str 在效率方面也是有天壤之别的。

写代码生涯中的第二个导师

这句话，我总觉得要被吐槽（如果被人看到的话）。我在生涯前面加了一个 写代码 的前缀， 其实我最先想到的词语是编程生涯，但停下想想不太对，编程和生活是好像是紧密关联的，而论生活的话， 这个视频于我就像那啥、沧海一粟？（今天使用的第二个成语，不过或许不那么恰当）。

coz，身边的朋友才是生活的主角丫丫丫，这一年半，自己还是很幸运的，（给自己一个啧啧啧表情） 已经非常幸运了 (๑•̀ㅂ•́)و✧ 。 下两年呐？会不会怀念这会儿，23333。应该会，但过去经验告诉我或许不会，其实还是会的，部分。 先立个 flag，以后来复习下，? ，23333 — 2018-6-28 20:47

自己读了一遍，有个问题，如果不附加一点信息，两年后肯定想不起今天发生了什么事情：

今天周四，天气很好，白天蓝云，这在最近的北京很少见。在北京五环边上的一个小工厂中，有个穿着服务员型衬衫的青年，低着头，弯着背，头发几乎遮住了整个眼睛，看着屏幕，敲着键盘。他左边的妹纸身在异国他乡，右边的大佬早已杳无音信，前面的汉纸最近也穿梭于各大会议室中。他在想着，两年后的今天，会是怎样呢？他还会记得同桌的他她它咩

2333，好，今天就这样吧 ～ 有点羞耻，其实。。。23333

Updated:

Comments