这里似乎有些东西一文不值。
首先,df_a.cumsum() 默认为axis=0(Pandas 没有在一次调用中对整个 DataFrame 求和的概念),而 NumPy 调用默认为axis=None。因此,通过在一个操作上指定一个轴并有效地压平另一个操作,您就是在将苹果与橙子进行比较。
也就是说,您可以比较三个调用:
>>> np.cumsum(df_a, axis=0)
>>> df_a.cumsum()
>>> val.cumsum(axis=0) # val = df_a.values
其中,在最终调用中,val 是底层 NumPy 数组,我们不计算在运行时获取 .values 属性。
所以,如果您在 IPython shell 中工作,请尝试使用 %prun 进行行分析:
>>> %prun -q -T pdcumsum.txt df_a.cumsum()
>>> val = df_a.values
>>> %prun -q -T ndarraycumsum.txt val.cumsum(axis=0)
>>> %prun -q -T df_npcumsum.txt np.cumsum(df_a, axis=0)
-T 将输出保存为文本,以便您可以查看所有三个相互匹配的内容。这是你最终的结果:
-
df_a.cumsum():186 个函数调用,0.022 秒。其中 0.013 用于numpy.ndarray.cumsum()。 (我的猜测是,如果没有 NaN,则不需要 nancumsum(),但请不要引用我的话)。另一个块用于复制数组。
-
val.cumsum(axis=0):5 次函数调用,0.020 秒。不进行复制(尽管这不是就地操作)。
-
np.cumsum(df_a, axis=0):204 个函数调用,0.026 秒。可以这么说,将 Pandas 对象传递给顶级 NumPy 函数似乎最终会调用 Pandas 对象上的等效方法,这会经历一大堆开销,然后重新调用 NumPy 函数。
现在,与%timeit 不同,您在这里只打了 1 个电话,就像在%time 中一样,所以我不会过分依赖与%prun 的相对时间差异;也许比较内部函数调用是有用的。但在这种情况下,当您为两者指定相同的轴时,时间差异实际上并没有那么大,即使 Pandas 的调用次数比 NumPy 的调用次数相形见绌。换句话说,在这种情况下,所有三个调用的时间都以np.ndarray.cumsum() 为主,辅助的 Pandas 调用不会占用太多时间。在其他情况下,辅助 Pandas 调用确实会消耗更多的运行时间,但这似乎不是其中之一。
大图——正如 Wes McKinney 的 acknowledged,
相当简单的操作,从索引到汇总统计,在到达最低层计算之前可能会经过多层脚手架。
在灵活性和增加功能之间进行权衡,你可以争论。
最后一个细节:在 NumPy 中,您可以通过调用实例方法 ndarray.cumsum() 而不是调用顶级函数 np.cumsum() 来 avoid a tiny bit of overhead,因为后者只是以 routing 结束于前者。但正如一位智者所说,过早的优化是万恶之源。
供参考:
>>> pd.__version__, np.__version__
('0.22.0', '1.14.0')