我有一个包含两列和一十多万个元素的DataFrame.
In [43]: df.head(10)Out[43]: localtime ref4 2014-04-02 12:00:00.273537 1390587547038105775 2014-04-02 12:00:02.223501 1390587547038105766 2014-04-02 12:00:03.518817 1390587547038105767 2014-04-02 12:00:03.572082 1390587547038105768 2014-04-02 12:00:03.572444 1390587547038105769 2014-04-02 12:00:03.572571 13905875470381057610 2014-04-02 12:00:03.573320 13905875470381057611 2014-04-02 12:00:09.278517 13905875470381057614 2014-04-02 12:00:20.942802 13905875470381057715 2014-04-02 12:01:13.410607 139058754703810576[10 rows x 2 columns]In [44]: df.dtypesOut[44]:localtime datetime64[ns]ref int64dtype: objectIn [45]: len(df)Out[45]: 111743In [46]: g = df.groupby('ref')
如果我从我的组中请求最后一个元素,该函数就会挂起!
In [47]: %timeit g.last()
我在6分钟后杀了它; top在整个时间内显示100%的cpu.
如果我明确地请求localtime列,这至少会返回,尽管对于有多少元素来说它仍然看起来很荒谬.
In [48]: %timeit g['localtime'].last()1 loops,best of 3: 4.6 s per loop
有什么我想念的吗?这是大熊猫0.13.1.
此问题与datetime64类型一起出现.假设我直接从文件中读取:
In [1]: import pandas as pdIn [2]: df = pd.read_csv('so.csv')In [3]: df.dtypesOut[3]:localtime objectref int64dtype: objectIn [4]: %timeit df.groupby('ref').last()10 loops,best of 3: 28.1 ms per loop
对象类型工作得很好.然而,如果我施展时间戳,所有地狱都会破裂:
In [5]: df.localtime = pd.to_datetime(df.localtime)In [6]: df.dtypesOut[6]:localtime datetime64[ns]ref int64dtype: objectIn [7]: %timeit df.groupby('ref').last()
情节变粗.
使用Jeff的建议在没有数据文件的情况下重现:
In [70]: rng = pd.date_range('20130101',periods=20,freq='s')In [71]: df = pd.DataFrame(dict(timestamp = rng.take(np.random.randint(0,20,size=100000)),value = np.random.randint(0,100,size=100000)*1000000))In [72]: %timeit df.groupby('value').last()1 loops,best of 3: 332 ms per loop
但是,如果我改变随机整数的范围,那么问题又会出现!
In [73]: df = pd.DataFrame(dict(timestamp = rng.take(np.random.randint(0,100000,size=100000)*1000))In [74]: %timeit df.groupby('value').last()
我只是增加了第二个randint()的高参数,这意味着groupby()将具有更大的长度.这会在没有数据文件的情况下重现我的错误.
请注意,如果我放弃datetime64类型,那么没有问题:
In [12]: df = pd.DataFrame(dict(timestamp = np.random.randint(0,size=100000),size=100000)*1000))In [13]: %timeit df.groupby('value').last()100 loops,best of 3: 14.4 ms per loop
所以罪魁祸首是在datetime64上缩放last().最佳答案必须是奇怪的事情……在0.13.1(和主人)看起来不错.发布您的文件的链接,我会看看.
In [3]: rng = date_range('20130101',freq='s')In [4]: df = DataFrame(dict(timestamp = rng.take(np.random.randint(0,size=100000)*1000000))In [5]: df.info()
好的,这里是解释:
使用np.random.randint(0,size = 100000)作为值,创建100个组,
而np.random.randint(0,size = 100000)创造了更多(在我的例子中)
63000)左右.
.last(in <0.14)implicity完成最后一个非nan值.这个na测试并不便宜,因此它具有较差的扩展性能(并且在每个组的python空间中完成).另一方面,尾部(1)(<0.14)不检查这一点,因此性能要好得多(并使用cython路由来获得结果).在0.14中这些将是相同的(即使你这样做:nth(-1,dropna =’any’)将复制最后在这里做的事情,这样做是为了有更好的性能.(谢谢@Andy Hayden).底线是在<中使用tail(1). 0.14. 总结
以上是内存溢出为你收集整理的python – groupby在熊猫中的最后一个性能问题全部内容,希望文章能够帮你解决python – groupby在熊猫中的最后一个性能问题所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)