使用gtk.FileChooserDialog选择大量文件时,与平台相关的性能问题

我有一个pygtk程序,旨在运行Windows和Ubuntu.它是Python 2.7和gtk2,带有静态绑定(即没有gobject内省).我遇到的问题存在于Ubuntu上但不存在于Windows上.

我的程序应该能够处理大量文件(这里我用大约200个测试),但每个文件的实际处理并不多.我基于每个文件对处理进行排队,并向用户呈现进度.

问题是在用gtk.FileChooserDialog选择文件后(control-A是你的朋友),程序挂起并且gtk事件在很长一段时间内都没有处理 – 即使我的回调函数已经返回.在此期间,所有核心上的CPU使用率大约持续80％,iotop显示我的进程以每秒约20MB的速度写入磁盘,其他应用程序间歇性地无响应 – Chrome,Xorg,compiz,banshee和gedit都具有高CPU使用率(在选择文件之前使用率较低).

这是一些示例代码.要重现,请单击按钮,从某处选择大约200个文件(大约十个屏幕保持移位和向下),然后单击“确定”.什么文件无关紧要 – 没有用它们做什么.

import gtk,gobject,time
def print_how_long_it_was_frozen():
print time.time() - start_time
def button_clicked(button):
dialog = gtk.FileChooserDialog(
'Select files to add', w, gtk.FILE_CHOOSER_ACTION_OPEN,
buttOns=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
gtk.STOCK_OPEN, gtk.RESPONSE_OK))
dialog.set_select_multiple(True)
dialog.set_default_response(gtk.RESPONSE_OK)
respOnse= dialog.run()
files = dialog.get_filenames()
dialog.destroy()
for i, f in enumerate(files):
print i
global start_time
start_time = time.time()
gobject.idle_add(print_how_long_it_was_frozen)
w = gtk.Window()
b = gtk.Button('Select files')
w.add(b)
b.connect('clicked', button_clicked)
w.show_all()
gtk.main()


这导致回调结束后约60秒挂起,在此期间除了处理对话框的破坏(在挂起的中途发生)之外不会发生任何事情.

这是在Ubuntu 11.10上.在Windows上,挂起的时间不到一秒钟.

我怀疑这是由于某些Gnome或Unity最近的文件功能,或其他活动跟踪.进程zeitgeist-daemon在挂起期间也有很高的CPU使用率,虽然查杀它并不能解决问题.也没有使用Zeitgeist活动日志管理器禁用日志记录.即使可以禁用Zeitgeist,我也不能指望我的用户禁用它.

有谁知道如何禁用gtk应用程序报告最近的文件,或知道可能导致此问题的任何其他内容？

相反,必须通过“选择文件夹”对话框添加非常大量的文件进行处理,但对于较少数量的文件,每个文件的挂起时间似乎约为半秒,否则对于其他文件来说这是不可接受的.响应式应用.

(测试是在32位Windows 7和64上进行的,但是Ubuntu 11.10.两者都是Python 2.7和pygtk 2.24)

解决方法:

减速是由于gtk.FileChooser小部件automatically将所有选定的文件放入最近使用的文件列表(gtk.RecentManager.add_item()).

在示例代码中添加此函数在单独的线程中运行(并且在挂起期间似乎没有问题获取gtk锁)：

def log_n_recent_files():
manager = gtk.recent_manager_get_default()
manager.purge_items()
while True:
time.sleep(1)
with gtk.gdk.lock:
items = manager.get_items()
with open('log.log','a') as f:
f.write('%f %d\n'%(time.time(), len(items)))


揭示(在隔夜运行之后)每个文件的延迟随着最近文件数量的增加而增加：

由于没有方法可以向RecentManager添加多个文件,因此每次添加一个文件.

每次添加一个,其他gtk应用程序会收到通知,即最近的文件列表(存储在〜/ .local / share / recent-used.xbel中)已更改.然后,他们解析文件并遍历项目,查找n个最新项目(其中n是特定于应用程序),以显示它们.在确定哪些文件是最新的时,每个项目为a system time call is made.

最近使用的xbel能够grow without limit这个事实加剧了这个问题.所以如果你在最近使用过的xbel中有5000个项目,并且你选择了带有gtk.FileChooser的200个文件,那么你将获得(总和)从n = 1到200)(5000 n)~100万系统时间调用每个gtk app运行.

gtk.Settings中有属性可以让你的应用程序查找历史记录中较少的文件,gtk-recent-files-limit和gtk-recent-files-max-age,但是它们不会阻止〜/ .local / share /最近用过的.来自写的.

为了防止最近使用过的xbel被写入,可以写保护它,或者用文件夹替换它.在这种情况下,gtk仍然会尝试添加所有文件,但每次尝试都会失败.每200个文件的延迟大约是1秒 – 我想这次尝试的开销仍然很大.

由于似乎无法关闭gtk.FileChooser的这种行为,唯一的另一种方法是使用不同的filechooser小部件.即使使用30000个文件,使用不推荐使用的gtk.FileSelection小部件时也没有明显的延迟.

这是一个丑陋的小部件,但我想我将不得不使用它并提交错误报告/功能请求,以便能够通过gtk.FileChooser禁用最近的文件报告.