奇怪的性能结果-循环vs列表理解和zip()

我遇到了一个非常简单的问题,当我试图找出哪种解决方案更快时,结果有些奇怪。

原始问题:给定两个列表ListAListB和一个常量k,请删除两个列表的总和为k的所有条目。

我用两种方法解决了这个问题:首先,我尝试使用循环,然后使用列表理解和zip()来压缩和解压缩两个列表。

使用循环的版本。

def Remove_entries_simple(listA,listB,k):
    """ removes entries that sum to k """
    new_listA = []
    new_listB = []
    for index in range(len(listA)):
        if listA[index] + listB[index] == k:
            pass
        else:
            new_listA.append(listA[index])
            new_listB.append(listB[index])
    return(new_listA,new_listB)

使用列表推导和zip()

的版本
def Remove_entries_zip(listA,k):
    """ removes entries that sum to k using zip"""
    zip_lists = [(a,b) for (a,b) in zip(listA,listB) if not (a+b) == k]

    # unzip the lists
    new_listA,new_listB = zip(*zip_lists)
    return(list(new_listA),list(new_listB))

然后,我尝试确定哪种方法更快。但是随后我得到了下图所示的内容(x轴:列表的大小,y轴:平均运行时间,重复10 ** 3)。由于某种原因,使用zip()的版本总是在相同的位置进行相同的跳转-我在不同的机器上多次运行了该跳转。有人可以解释导致这种奇怪行为的原因吗?

奇怪的性能结果-循环vs列表理解和zip()

更新:我用来生成绘图的代码。我使用函数装饰器将每个问题运行1000次。

导入语句:

import random
import time
import matplotlib.pyplot as plt

函数装饰器:

def Repetition_Decorator(fun,Rep=10**2):
    ''' returns the average over Rep repetitions'''
    def Return_function(*args,**kwargs):
        Start_time = time.clock()
        for _ in range(Rep):
            fun(*args,**kwargs)
        return (time.clock() - Start_time)/Rep

return Return_function

创建绘图的代码:

Zippedizip = []
Loops = []
The_Number = 10
Size_list = list(range(10,1000,10))

Repeated_remove_loop = Repetition_Decorator(Remove_entries_simple,Rep=10**3)
Repeated_remove_zip = Repetition_Decorator(Remove_entries_zip,Rep=10**3)

for size in Size_list:
    ListA = [random.choice(range(10)) for _ in range(size)]
    ListB = [random.choice(range(10)) for _ in range(size)]

    Loops.append(Repeated_remove_loop(ListA,ListB,The_Number))
    Zippedizip.append(Repeated_remove_zip(ListA,The_Number))

plt.xlabel('Size of List')
plt.ylabel('Averaged time in seconds')
plt.plot(Size_list,Loops,label="Using Loop")
plt.plot(Size_list,Zippedizip,label="Zip")
plt.legend(loc='upper left',shadow=False,fontsize='x-large')
plt.show()

更新-更新:感谢kaya3指出了timeit模块。

为尽可能接近我的原始代码,同时也使用timeit模块,我创建了一个新的函数装饰器,该装饰器使用timeit模块对代码进行计时。

新装饰器:

def Repetition_Decorator_timeit(fun,Rep=10**2):                                                                                   
"""returns average over Rep repetitions with timeit"""                                                                         
    def Return_function(*args,**kwargs):                                                                                          
        partial_fun = lambda: fun(*args,**kwargs)                                                                                 
        return timeit.timeit(partial_fun,number=Rep) / Rep                                                                        
return Return_function 

当我使用新的装饰器时,使用for循环的版本不受影响,但是zip版本不再起作用。

奇怪的性能结果-循环vs列表理解和zip()

到目前为止,我可以肯定的是,跳转是由于我对函数的度量而不是函数本身的结果。但是跳转是如此独特-在不同机器上始终具有相同的列表大小-不能cannot幸。为什么会发生这种跳跃的任何想法?

更新-更新-更新:

这与垃圾收集器有关,因为如果我用gc.disable()禁用垃圾收集器,则两种测量方法都会得出相同的结果。

奇怪的性能结果-循环vs列表理解和zip()

我在这里学到了什么:不要只自己衡量执行时间。使用timeit模块来测量代码段的性能。

tns1986 回答:奇怪的性能结果-循环vs列表理解和zip()

这似乎是您测量运行时间的一种方法。我不知道是什么原因导致您的计时代码产生这种效果,但是当我使用timeit来衡量运行时间时,该效果消失了。我正在使用Python 3.6.2。

我可以使用您的定时代码来始终如一地重现效果;我得到zip版本的运行时间以相同的阈值跳跃,尽管它仍然比我机器上的其他版本略快:

Timed using clock

但是,当我使用timeit测量时间时,效果会完全消失:

enter image description here

这是使用timeit的代码;我对您的分析代码所做的更改尽可能少。

import timeit

Zippedizip = []
Loops = []
The_Number = 10
Size_list = list(range(10,1000,10))
Reps = 1000

for size in Size_list:
    ListA = [random.choice(range(10)) for _ in range(size)]
    ListB = [random.choice(range(10)) for _ in range(size)]

    remove_loop = lambda: Remove_entries_simple(ListA,ListB,The_Number)
    remove_zip = lambda: Remove_entries_zip(ListA,The_Number)

    Loops.append(timeit.timeit(remove_loop,number=Reps) / Reps)
    Zippedizip.append(timeit.timeit(remove_zip,number=Reps) / Reps)

# ...

所以我认为这是一个虚假的结果。就是说,我不明白您的计时代码是由什么引起的。我尝试简化您的计时代码,以不使用修饰符或变量,然后将time.clock()替换为time.perf_counter(),它更准确,但没有任何改变。

,

使用zip在列表中并行迭代,同时使用append求和的版本似乎更加一致。

我认为我们在zip(*...)上看到的是,将(*)迭代器散布到参数列表中有一个阈值(也许是768个参数?),然后才开始使用慢速方法。

def Remove_entries_halfzip(listA,listB,k):
    """ removes entries that sum to k using zip"""
    new_listA = []
    new_listB = []
    for a,b in zip(listA,listB):
        if a + b != k:
            new_listA.append(a)
            new_listB.append(b)

    return (new_listA,new_listB)

Chart

您可以通过使append函数成为局部函数,并为每次迭代保存属性查找,来进一步进行微优化:

def Remove_entries_halfzip_micro_opt(listA,k):
    """ removes entries that sum to k using zip"""
    new_listA = []
    new_listB = []
    append_a = new_listA.append
    append_b = new_listB.append
    for a,listB):
        if a + b != k:
            append_a(a)
            append_b(b)

    return (new_listA,new_listB)

enter image description here

我也尝试了Numpy实现,但是由于所需的数据转换(每次调用都进行{np.array()强制转换),它的速度较慢。如果您一直在使用Numpy阵列,则速度会更快。

本文链接:https://www.f2er.com/3098755.html

大家都在问