Am 28.04.2010 10:36, schrieb Thomas Martitz:
Am 27.04.2010 23:00, schrieb Colomban Wendling:
I noticed this long time ago already and it's quite annoying and needs to be fixed. My first guess without having done any investigations, we are doing too much UI updating stuff on bulk loading of files (e.g. the previously mentioned resorting of the document list, there are probably many more such issues).
I think it isn't only UI stuff because my system monitor shows me (lot of) I/O, that seems to be heavy disk *writes*, in addition to simple CPU usage. Note that this happens effectively only after the files being loaded (hum, after the info about them are shown).
Haha, got it! Thanks to gdb, I found what takes all this time: GtkRecentManager, and particularly gtk_recent_manager_add_item(manager, uri) at line 1037 of ui_utils.c. Why? well, it seems to syncs its state at each and every addition, and the g_file_set_contents(), which calls… fsync(). Commenting the addition completely fixes the problem after file loading. Now it takes about 11 seconds, to load the files (always as reported by the verbose messages). Time to search for a but report on GTK I think.
40 seconds for 235 files here. Still largely annoying, I frequently switch projects which is basically a pain. This 235 are part of a project. A real one which I use, not just a test case.
Can the recent manager be disabled for projects? The files are collected in projects and there's the recent project list, so I don't see a need to add files that belong to a project to the recent files list.
To be honest, I never use the recent files feature. 11 seconds sounds like a dream.
Best regards.
I did a test as well. I commented out the two add_recent_file() calls, and loading my 235-files project now takes 25 seconds, which is better but nowhere near your 11 seconds. But I noticed the HDD led doesn't blink anymore during the file opening so I'd say I can confirm I/O usage is heavily reduced (no writes).
Best regards.