Hi!
As some of you might have noticed, the sorting in the "Documents" side panel is not perfect when extensions are involved. For example, if you have the three files a.c, a.h and a-b.c, they will be sorted in the following order [1]: a.c, a-b.c, a.h rather than [2]: a.c, a.h, a-b.c This is a little annoying to find the a.h file.
As you expected, I've written a patch to fix this, an I propose it here. Hum, well no: I've written two different patches. Why? Both have advantages and inconveniences over the other. Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
The difference between the two patches is the way thy integrate in Geany.
0001-improved-documents-sorting.diff: This one is small, almost no code changes, and don't persistently use more memory. But OTHO, it computes the collate key of both names to compare each and every time the sort function is called.
0001-improved-documents-sorting-2.diff: This one is probably faster, but persistently use a little more memory: it computes the collate key only when adding the item, and stores it in the tree model. Another "advantage" of it is that it easily allow to use different collate functions for files and directories - not sure it is useful.
Then, there are the two patches, I let you chose/discuss the one is the better if you're interested.
Regards, Colomban
[1] without the patch, http://ban.free-h.net/geany/improved-documents-sorting/before.png [2] with the patch: http://ban.free-h.net/geany/improved-documents-sorting/after.png
Am 26.04.2010 15:42, schrieb Colomban Wendling:
Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
I'm quite confident you cannot achieve that with strcmp() (1 comes after 2 no matter if there's a following 0 or not). You'd need something like strnatcmp[1], which we use quite happily in Rockbox since a while, for that.
Best regards.
Thomas Martitz a écrit :
Am 26.04.2010 15:42, schrieb Colomban Wendling:
Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
I'm quite confident you cannot achieve that with strcmp() (1 comes after 2 no matter if there's a following 0 or not). You'd need something like strnatcmp[1], which we use quite happily in Rockbox since a while, for that.
Hum, not sure what you mean… Actually, g_utf8_collate_key_for_filename() do the trick quite well, supports full UTF-8 and honor locale-specific rules. I don't see need for a replacement here, do you?
Regards, Colomban
PS: sorry Thomas for the double post, I messed up with my mail client and didn't responded to the list…
Am 26.04.2010 17:17, schrieb Colomban Wendling:
Hum, not sure what you mean… Actually, g_utf8_collate_key_for_filename() do the trick quite well, supports full UTF-8 and honor locale-specific rules. I don't see need for a replacement here, do you?
Oh, I'm sorry, I didn't see g_utf8_collate_key_for_filename(), I only saw strcmp in the comparator function. Nevermind then!
Best regards.
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
As some of you might have noticed, the sorting in the "Documents" side panel is not perfect when extensions are involved. For example, if you have the three files a.c, a.h and a-b.c, they will be sorted in the following order [1]: a.c, a-b.c, a.h rather than [2]: a.c, a.h, a-b.c This is a little annoying to find the a.h file.
As you expected, I've written a patch to fix this, an I propose it here. Hum, well no: I've written two different patches. Why? Both have advantages and inconveniences over the other. Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
The difference between the two patches is the way thy integrate in Geany.
0001-improved-documents-sorting.diff: This one is small, almost no code changes, and don't persistently use more memory. But OTHO, it computes the collate key of both names to compare each and every time the sort function is called.
0001-improved-documents-sorting-2.diff: This one is probably faster, but persistently use a little more memory: it computes the collate key only when adding the item, and stores it in the tree model. Another "advantage" of it is that it easily allow to use different collate functions for files and directories - not sure it is useful.
Then, there are the two patches, I let you chose/discuss the one is the better if you're interested.
First: thanks.
Then, I'm no sure. It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while testing. Though re-sorting the list on tab switching seems weird, maybe there is a reason but without looking into it, it feels like a bug.
I'm not yet sure. Maybe we first should try to reduce sorting attempts to a minimum...:).
Regards, Enrico
On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
As some of you might have noticed, the sorting in the "Documents" side panel is not perfect when extensions are involved. For example, if you have the three files a.c, a.h and a-b.c, they will be sorted in the following order [1]: a.c, a-b.c, a.h rather than [2]: a.c, a.h, a-b.c This is a little annoying to find the a.h file.
As you expected, I've written a patch to fix this, an I propose it here. Hum, well no: I've written two different patches. Why? Both have advantages and inconveniences over the other. Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
The difference between the two patches is the way thy integrate in Geany.
0001-improved-documents-sorting.diff: This one is small, almost no code changes, and don't persistently use more memory. But OTHO, it computes the collate key of both names to compare each and every time the sort function is called.
0001-improved-documents-sorting-2.diff: This one is probably faster, but persistently use a little more memory: it computes the collate key only when adding the item, and stores it in the tree model. Another "advantage" of it is that it easily allow to use different collate functions for files and directories - not sure it is useful.
Then, there are the two patches, I let you chose/discuss the one is the better if you're interested.
First: thanks.
Then, I'm no sure. It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
testing. Though re-sorting the list on tab switching seems weird, maybe there is a reason but without looking into it, it feels like a bug.
I'm not yet sure. Maybe we first should try to reduce sorting attempts to a minimum...:).
Ok, the re-sorting on tab switching was wrong and should be fixed in SVN now. Not strictly related to whole topic but nice that we found it by talking about the topic :).
Regards, Enrico
Enrico Tröger a écrit :
On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
Hey!
It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
I just did naive and inexact benchmarks (with a watch, haha), and it seems that the naive solution is not so slow (tested with "only" 300 files: 122s vs 125s [1]); and the more complex solution seems to be as fast as without any special sorting function. So I think I'll vote too for the naive solution - and anyway, is there anybody here that uses an editor with 300 files at once?
Offtopic: But but but… opening 300 empty files with no filetype (loaded as None) took more than 120s! Even though Gedit took 89s to load the same 300 files, I think there is a little problem somewhere. Investigating this would be interesting.
Ok, the re-sorting on tab switching was wrong and should be fixed in SVN now. Not strictly related to whole topic but nice that we found it by talking about the topic :).
Nice one :)
Regards, Colomban
[1] But this is not precise, might be actually 123s vs. 124s…
On Tue, 27 Apr 2010 18:05:05 +0200, Colomban wrote:
Enrico Tröger a écrit :
On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
Hey!
It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
I just did naive and inexact benchmarks (with a watch, haha), and it seems that the naive solution is not so slow (tested with "only" 300 files: 122s vs 125s [1]); and the more complex solution seems to be as fast as without any special sorting function. So I think I'll vote too for the naive solution - and anyway, is there anybody here that uses an editor with 300 files at once?
Not 300, but I recently noticed that I'm working with more than 100 currently open files at work. Didn't expected that, I just thought 'uh, many open files' but having a look on the status messages, told me I had some 120 files open or so. I never ever expected that someone uses Geany that way and then, this someone was even me...:).
Offtopic: But but but… opening 300 empty files with no filetype (loaded as None) took more than 120s! Even though Gedit took 89s to load the same 300 files, I think there is a little problem somewhere. Investigating this would be interesting.
I doubt it would be interesting but necessary. 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).
Regards, Enrico
Enrico Tröger a écrit :
Offtopic: But but but… opening 300 empty files with no filetype (loaded as None) took more than 120s! Even though Gedit took 89s to load the same 300 files, I think there is a little problem somewhere. Investigating this would be interesting.
I doubt it would be interesting but necessary.
Well, yes indeed.
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).
Regards, Colomban
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.
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.
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.
Thomas Martitz a écrit :
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.
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
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).
Remember that I used 300 *empty* files with *no filetype*, which means that any thing Geany does to detect file type, encoding, load tags files, etc. is reduced at the minimum. I don't expect it would be the same with 300 real files. This to say that yes, the recent manager takes way to much resources, but of course there's probably other rooms for improvements.
Can you try to run Geany with the -v switch (verbose) and measure the time it takes to load all the files (detecting file type, etc.)?
Regards, Colomban
On Wed, 28 Apr 2010 14:08:47 +0200, Colomban wrote:
Thomas Martitz a écrit :
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.
For project files, gtk_recent_manager_add_item() isn't called at all. It is only used when opening single files.
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :). But it would kinda workaround the bug in the current implementation.
Regards, Enrico
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I think this is a better workaround until the GTK bug is fixed. In fact, we might keep the workaround for e.g. 2.10, 2.12, etc if the fix is only in the most recent version(s).
Regards, Nick
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
In fact, we might keep the workaround for e.g. 2.10, 2.12, etc if the fix is only in the most recent version(s).
Yes, I don't think GTK maintainers would release patch for the older versions. Perhaps distributions would do so, but I doubt -- it is not a security fix, only usability, and that have a significant impact only when dealing with lot of files.
Regards, Colomban
On Thu, 29 Apr 2010 18:47:41 +0200, Colomban wrote:
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
I'm not sure what you mean. Only add the last 10 files when opening multiple files at once?
Another idea: maybe we could add a similar workaround as you did in your patch you attached to the GTK bug report: we 'collect' filenames added to the GtkRecentManager instead of adding them directly and then add them bulky in an idle function. That wouldn't really solve the problem but at least put the IO heavy part into one block at the end of loading files.
Regards, Enrico
On Thu, 29 Apr 2010 18:47:41 +0200, Colomban wrote:
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
I'm not sure what you mean. Only add the last 10 files when opening multiple files at once?
Yes. Or even better than "the last 10", the number returned by gtk_recent_manager_get_limit().
Another idea: maybe we could add a similar workaround as you did in your patch you attached to the GTK bug report: we 'collect' filenames added to the GtkRecentManager instead of adding them directly and then add them bulky in an idle function. That wouldn't really solve the problem but at least put the IO heavy part into one block at the end of loading files.
Hum, yes it's an idea, but as you said there still will be the problem, it will only happen later. I'm not sure it would be better, but without testing it is probably impossible to say.
Regards, Colomban
PS: I'll probably be a little unresponsive these days because of some problem with my computer hardware hope it'll be fixed soon.
On Sat, 8 May 2010 15:37:53 +0200 (CEST), lists.ban@herbesfolles.org wrote:
On Thu, 29 Apr 2010 18:47:41 +0200, Colomban wrote:
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, I think it could be a (hidden?) option at least until it got fixed at the GTK level. Note that anyway it is only available if Geany was compiled against GTK >= 2.12.
Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
I'm not sure what you mean. Only add the last 10 files when opening multiple files at once?
Yes. Or even better than "the last 10", the number returned by gtk_recent_manager_get_limit().
According to the docs, the "limit" property defaults to -1 which probably means 'no limit'. So, if the default is no limit, we would not gain much by it, I'm afraid. Am I missing something?
Regards, Enrico
On Sat, 8 May 2010 15:37:53 +0200 (CEST), lists.ban@herbesfolles.org wrote:
On Thu, 29 Apr 2010 18:47:41 +0200, Colomban wrote:
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
> Yes, I think it could be a (hidden?) option at least until it > got fixed at the GTK level. Note that anyway it is only > available if Geany was compiled against GTK >= 2.12. Which is probably true for most Geany users (using GTK >= 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
Maybe we could generally disable calling gtk_recent_manager_add_item() when opening more than one file at once because maybe the user doesn't want to have them added at all. Though, no idea if this is a valid assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
I'm not sure what you mean. Only add the last 10 files when opening multiple files at once?
Yes. Or even better than "the last 10", the number returned by gtk_recent_manager_get_limit().
According to the docs, the "limit" property defaults to -1 which probably means 'no limit'. So, if the default is no limit, we would not gain much by it, I'm afraid. Am I missing something?
Hum, no you're right, I talked way too fast. The number of actually displayed items is in GtkSettings:gtk-recent-files-limit. But the default seems to be 50 (on a Ubuntu 8.10 live CD at least), which is still a lot to add -- less than 300 but still. But hum, do you set it yourself in geany? (since there is only 10 actually displayed IIRC)
Regards, Colomban
On Sun, 9 May 2010 15:33:47 +0200 (CEST), Colomban wrote:
On Sat, 8 May 2010 15:37:53 +0200 (CEST), lists.ban@herbesfolles.org wrote:
On Thu, 29 Apr 2010 18:47:41 +0200, Colomban wrote:
Nick Treleaven a écrit :
On Thu, 29 Apr 2010 17:46:45 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
>> Yes, I think it could be a (hidden?) option at least until >> it got fixed at the GTK level. Note that anyway it is only >> available if Geany was compiled against GTK >= 2.12. > Which is probably true for most Geany users (using GTK >= > 2.12).
(After a quick Grep it seems to me it's 2.10, not 2.12).
Yes, actually. I don't know why I've said 2.12 sorry.
> Maybe we could generally disable calling > gtk_recent_manager_add_item() when opening more than one > file at once because maybe the user doesn't want to have > them added at all. Though, no idea if this is a valid > assumption and also no idea how to verify it :).
I don't think so. I use that recent files feature, not that much but I use it. And I would be definitely surprised if a file is added to it if I open it alone but not if I open another file together. But of course if we open 15 files and only 10 are shown in the recent list, the first 5 might haven't be added at all. It would probably be a little tricky to do that but it's probably the less wrong workaround.
I'm not sure what you mean. Only add the last 10 files when opening multiple files at once?
Yes. Or even better than "the last 10", the number returned by gtk_recent_manager_get_limit().
According to the docs, the "limit" property defaults to -1 which probably means 'no limit'. So, if the default is no limit, we would not gain much by it, I'm afraid. Am I missing something?
Hum, no you're right, I talked way too fast. The number of actually displayed items is in GtkSettings:gtk-recent-files-limit. But the default seems to be 50 (on a Ubuntu 8.10 live CD at least), which is still a lot to add -- less than 300 but still. But hum, do you set it yourself in geany? (since there is only 10 actually displayed IIRC)
In Geany, we don't use the GTK setting but our own instead. This is because our setting is older than GTK's :). The GtkRecentManager exists only since GTK 2.10 but our MRU list implementation is older IIRC. We only add the recent files to GTK's system so they are visible there.
Regards, Enrico
Am 29.04.2010 17:46, schrieb Enrico Tröger:
On Wed, 28 Apr 2010 14:08:47 +0200, Colomban wrote:
Thomas Martitz a écrit :
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.
For project files, gtk_recent_manager_add_item() isn't called at all. It is only used when opening single files.
Then I find it strange that commenting out the calls had an effect actually.
Best regards.
On Thu, 29 Apr 2010 19:04:13 +0200, Thomas wrote:
Am 29.04.2010 17:46, schrieb Enrico Tröger:
On Wed, 28 Apr 2010 14:08:47 +0200, Colomban wrote:
Thomas Martitz a écrit :
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.
For project files, gtk_recent_manager_add_item() isn't called at all. It is only used when opening single files.
Then I find it strange that commenting out the calls had an effect actually.
Me too. In my tests, I could reproduce Colomban's report of heavy disk IO and lightning HDD led. After I commented out the gtk_recent_manager_add_item() call, the disk IO was gone and loading of files was faster. But I'm really sure this code isn't called when opening projects. If in doubt, just add a simple debug output shortly before or after the call in the code or use a debugger and set a breakpoint. If it is hit, I'm probably wrong :).
Regards, Enrico
Colomban Wendling a écrit :
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.
I reported this to GTK, and written a small (and probably not perfect) patch that fixes the problem: https://bugzilla.gnome.org/show_bug.cgi?id=616997 Hope somebody take a look at this and fix it in the next GTK release.
On Wed, 28 Apr 2010 14:08:12 +0200, Colomban wrote:
Colomban Wendling a écrit :
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.
I reported this to GTK, and written a small (and probably not perfect) patch that fixes the problem: https://bugzilla.gnome.org/show_bug.cgi?id=616997 Hope somebody take a look at this and fix it in the next GTK release.
Thanks so much for taking the time to investigate the issue, report it and even provide a patch for GTK. Let's hope it'll get fixes soon.
Regards, Enrico
On Tue, 27 Apr 2010 18:05:05 +0200, Colomban wrote:
Enrico Tröger a écrit :
On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
Hey!
It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
I just did naive and inexact benchmarks (with a watch, haha), and it seems that the naive solution is not so slow (tested with "only" 300 files: 122s vs 125s [1]); and the more complex solution seems to be as fast as without any special sorting function. So I think I'll vote too for the naive solution - and anyway, is there anybody here that uses an editor with 300 files at once?
Before the patch gets lost, I'd like to commit it soon if there are no objections.
Regards, Enrico
On Sat, 8 May 2010 14:24:21 +0200, Enrico wrote:
On Tue, 27 Apr 2010 18:05:05 +0200, Colomban wrote:
Enrico Tröger a écrit :
On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
Hey!
It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
I just did naive and inexact benchmarks (with a watch, haha), and it seems that the naive solution is not so slow (tested with "only" 300 files: 122s vs 125s [1]); and the more complex solution seems to be as fast as without any special sorting function. So I think I'll vote too for the naive solution - and anyway, is there anybody here that uses an editor with 300 files at once?
Before the patch gets lost, I'd like to commit it soon if there are no objections.
Committed now. Thanks again for the patch and the many efforts.
Regards, Enrico